fix(wintermute): distinguish an absent record row from a stale delete

[afbase]

Summary

Builds on #223. The delete path treats "no record row deleted" as a lost race and skips the typed cleanup, so the typed row is orphaned whenever the record row is simply absent rather than newer. #223 works around that by forcing the cascade for the boilerplate collections (like, repost, follow, block), which fixes the common case but does it unconditionally: a delete carrying an older rev than a surviving record row now cascades into a live typed row, and the error from the record delete is discarded.

This returns the deletion outcome instead of a bool. An absent record row cascades; a surviving newer rev does not; and the distinction holds for every collection rather than only the boilerplate set. Practical exposure of the stale-rev case is small — rkeys are TIDs, so delete-then-recreate at the same key is rare — so this is a correctness cleanup rather than an urgent fix.

Stacked on #227; review that one first. Retarget to main once it merges.

Test plan

• cargo clippy -p rsky-wintermute --all-targets is clean
• cargo test -p rsky-wintermute --lib against a schema-loaded Postgres, including the two added cases: cascade with the skip off and the record row absent, and no cascade for a stale-rev delete with the skip on
• cargo llvm-cov -p rsky-wintermute
• cargo build --release -p rsky-wintermute
• Confirm the stale-writes-skipped counter moves for a stale delete and stays flat for an absent record row