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

• chore(engine): publish engine bases in ci #4649
• chore: lockfile lefthook #4647
• 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

This is a clean, targeted optimization that replaces manual chunk enumeration with a range delete in the SQLite VFS truncate path. Both implementations maintain parity per the CLAUDE.md requirement.

What the change does

Before: For truncation, the code built a list of individual chunk keys from last_chunk_to_keep + 1 to last_existing_chunk, then deleted them in batches of KV_MAX_BATCH_KEYS.

After: A single kv_delete_range / deleteRange call from the first chunk to delete up to get_chunk_key_range_end(file_tag) (the exclusive upper bound for all chunks of this file).

Correctness

Range boundary is safe. get_chunk_key_range_end(file_tag) returns [SQLITE_PREFIX, SCHEMA_VERSION, CHUNK_PREFIX, file_tag + 1], which is lexicographically strictly greater than any 8-byte chunk key for file_tag and strictly less than any key for file_tag + 1. No keys from adjacent file tags can be deleted.

Semantically broader than old code, but intentionally so. The old code was bounded by last_existing_chunk (derived from file.size). The new code deletes everything from the truncation point through the end of the file tag's key namespace. This is actually more robust: it cleans up any orphaned chunks beyond what file.size tracks (e.g., from a prior crash). This matches the behavior already used in delete_file.

Zero-size truncation works correctly. When size == 0, last_chunk_to_keep == -1, so the start key is get_chunk_key(file_tag, 0) — all chunks are deleted. In Rust, the cast (-1i64 + 1) as u32 == 0u32 is correct.

Guard condition is correct. The last_chunk_to_keep < last_existing_chunk guard (added in both files) prevents a spurious delete call when no chunks need removal.

Minor observations

Removed comment in TypeScript. The old code had // Delete chunks beyond the new size which explained the loop's purpose. The new code is simple enough to be self-evident, but a brief comment on the deleteRange call (similar to the Rust doc comment on get_chunk_key_range_end) could be helpful for future readers. Optional callout, not a blocker.

Pre-existing overflow concern (not introduced here). In Rust, get_chunk_key_range_end does file_tag + 1 on a u8. If file_tag == 255, this overflows in debug mode. This same function is already used in delete_file, so it's pre-existing and out of scope for this PR.

No test changes. Correctness of range delete vs. batch delete is implementation-level; the observable behavior is identical. Existing truncation tests should cover this. No new tests needed solely for this refactor.

Summary

Straightforward improvement: fewer allocations, fewer round-trips for large files, parity maintained between Rust and TypeScript. The logic is correct and the approach is consistent with how delete_file already works. Looks good to me.