perf(sqlite-native): remove delete file existence probe

[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]

• chore(engine): publish engine bases in ci #4649 : 3 dependent PRs (#4650 , #4652 , #4666 )
• 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
• 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 👈 (View in Graphite)
• 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: perf(sqlite-native): remove delete file existence probe

Summary: This PR removes a kv_get existence check from VfsContext::delete_file in the native Rust VFS before issuing kv_delete_range + kv_delete. The goal is to eliminate a redundant KV round-trip on every file deletion.

---

Correctness

The optimization is sound. kv_delete_range and kv_delete on a range/key with no matching data are no-ops at the KV level in all reasonable implementations. SQLite's VFS contract for xDelete does not require the function to error if the file is absent. The old guard read was purely defensive.

Parity concern with the WASM VFS. The TypeScript #delete method in the WASM VFS still performs the existence probe:

const sizeData = await options.get(metaKey);
if (!sizeData) {
    return; // File doesn't exist, that's OK
}
await options.deleteRange(...);
await options.deleteBatch([metaKey]);

The native and WASM implementations now diverge for this code path. The WASM VFS comment already treats the absent-file case as a no-op, it just avoids the deleteRange call. The net effect is the same (no corruption), but the WASM VFS now avoids one unnecessary deleteRange call that the native VFS always issues.

Recommendation: Either remove the existence probe from the WASM #delete as a follow-up (aligning behavior), or add a comment to delete_file in vfs.rs noting the intentional divergence and why it's safe.

---

Performance

The optimization is valid. The removed code was an unconditional synchronous block_on KV round-trip before every delete_file call. File deletions occur on xDelete (journaling cleanup) and xClose with SQLITE_OPEN_DELETEONCLOSE (temp files), so this could fire frequently. Saving a full KV round-trip here is a meaningful latency win.

---

Potential Issue: Empty-range delete_range contract

The removed code returned Ok(()) early if the file didn't exist, short-circuiting both kv_delete_range and kv_delete. The new code always issues both calls. If any SqliteKv backend treats a delete_range over an empty range as an error rather than a no-op, the behavior changes from silently succeeding to propagating an error. The trait doc says "Delete all keys in the half-open range [start, end)" but does not explicitly document the empty-range case. Worth confirming all concrete implementations handle empty ranges gracefully.

---

Summary

Concern	Severity
Optimization correctness	Sound
WASM VFS parity divergence	Low — follow-up recommended
Empty-range delete_range contract	Low — implicit assumption worth documenting
Code quality	Clean

Overall: The change is correct and the performance gain is real. The main gap is that the WASM VFS counterpart still has the existence probe, creating a parity divergence. A follow-up to align the WASM side or add an explicit comment would close this out cleanly.