fix(sqlite-vfs): use delete range for truncate cleanup

[NathanFlurry]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[NathanFlurry]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix(rivetkit): surface native sqlite kv errors to callers #4645
• fix(rivetkit): prevent sleep races during disconnect and db work #4644
• fix(rivetkit): isolate engine envoys and propagate startup failures #4643
• test(rivetkit): remove wasm sqlite-only fixtures and coverage #4642
• chore(sqlite-vfs): remove wasm sqlite packages and workspace wiring #4641
• chore(rivetkit): remove wasm sqlite runtime #4614
• fix(sqlite-native): restore native startup kv preload #4639
• fix(sqlite-native): delete metadata before chunk range #4638
• fix(sqlite-native): keep truncate cache coherent #4637
• fix(sqlite-vfs): use delete range for truncate cleanup #4636 👈 (View in Graphite)
• fix(sqlite-native): restore kv error hook #4635
• perf(sqlite-native): avoid cloning cached read chunks #4634
• perf(sqlite-native): gate kv operation labels #4633
• perf(sqlite-native): reuse read cache for partial writes #4632
• perf(sqlite-native): remove delete file existence probe #4631
• fix(sqlite-native): gate native read cache behind env var #4630
• fix(pegboard): isolate runner config dc lookup failures #4625 : 1 other dependent PR (#4626 )
• docs(pegboard): note runner config upsert split write risk #4624
• fix(pegboard): unpack global runner config keys correctly #4623
• fix(pegboard-gateway): enforce tunnel message state #4622
• fix(pegboard-runner): clear terminal tunnel routes #4621
• fix(pegboard): skip protocol version keys in runner pool backfill #4620
• fix(pegboard): create missing normal runner configs #4619
• fix(epoxy): reuse cached optimistic value #4618
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[claude]

PR Review: fix(sqlite-vfs): use delete range for truncate cleanup

Summary

This PR simplifies the xTruncate path in both the Rust native VFS (sqlite-native/src/vfs.rs) and the TypeScript WASM VFS (sqlite-vfs/src/vfs.ts) by replacing a per-chunk enumeration loop with a single kv_delete_range / deleteRange call. This is a clean, correct optimization that mirrors the existing pattern already used in delete_file.

---

Correctness

Range bounds are correct. The start key get_chunk_key(file_tag, last_chunk_to_keep + 1) and end key get_chunk_key_range_end(file_tag) correctly cover all surplus chunks. This is the same half-open range pattern already used in the delete_file path (e.g., vfs.rs:311-313).

size == 0 edge case. When size == 0, last_chunk_to_keep = -1, so (last_chunk_to_keep + 1) as u32 = 0 -- the range correctly starts at chunk 0, deleting everything. Same logic holds in TypeScript.

Broader end bound is strictly safer. The old loop terminated at lastExistingChunk, which could miss orphaned chunk keys written past the last-known chunk (e.g., from a partial write before a crash). The new end bound getChunkKeyRangeEnd(fileTag) covers all keys for the file tag up to the key-space boundary, eliminating that class of orphan leak.

VFS parity maintained. Both implementations are updated identically, satisfying the requirement that the native Rust VFS and WASM TypeScript VFS match 1:1, including the delete/truncate strategy.

Guard condition is correct. The if last_chunk_to_keep < last_existing_chunk guard is present in both implementations, correctly skipping the deleteRange call when there is nothing to delete.

---

Suggestions

Missing test coverage. The PR checklist item for tests is unchecked, and no tests are included. The main regression risk is the >128-chunk case -- the old code issued multiple kv_delete batches, and the new single deleteRange must cover the same key space. Recommend adding tests for:

• Truncating a file with >128 chunks (>512 KiB), verifying all surplus chunks are gone after truncation.
• Truncating to size == 0 (all chunks deleted).
• Truncating when lastChunkToKeep == lastExistingChunk (guard path, no-op).

Missing comment in TypeScript. The old block had // Delete chunks beyond the new size. The new block has no comment. Since the end bound (getChunkKeyRangeEnd) is broader than strictly necessary (it covers the entire file-tag key space rather than just chunks up to lastExistingChunk), a brief comment explaining the intent would help future readers understand why the broader range is deliberate.

PR description is empty. The boilerplate template was left unfilled -- no summary, no test description, no checklist items checked. Worth filling in for reviewability.

---

No Issues Found

• No bugs detected.
• Error handling (is_err() / SQLITE_IOERR_TRUNCATE) is unchanged and correct.
• KV_MAX_BATCH_KEYS is still used in the write path -- no dead code introduced.
• No security implications -- internal storage optimization with no change to trust boundaries or key schema.

Overall: clean change, correct semantics, recommend approval pending test coverage.