#2892 Extension datastore: query still returns an item after its delete is pulled

Summary

On an extension datastore (S3, GCS), after a peer's delete reaches a repo through a pull, DataQueryService.query in that repo still returns the deleted item. getLatestRecord correctly returns null.

Found while working on swamp-club#2856 / #2858.

Reproduction (in-process, in-memory remote)

1. Repos A and B on one createInMemoryRemote({ semantics: { pullDeletes: true } }) (the default fake reproduces the extensions' current pull, which does not delete local files at all, see note below).
2. A saves item x, pushes. B pulls, queries: [x v2].
3. A deletes x, pushes. B pulls (synced=true), invalidates the catalog.
4. B getLatestRecord("m1", "x") returns null, but query('modelName == "m1" && name == "x"') still returns [2].

Why

• Full backfill is additive by design (swamp-club#1581): it upserts rows found on disk and never removes rows, so rows for remote-only metadata under lazy hydration survive.
• Custom datastores construct DataQueryService with filterStaleRows: false (repo_context.ts), so query does not hide rows whose files are gone; filesystem datastores set it to true.
• So the deleted item's row survives the backfill and is returned.

Notes

• The obvious fix (replace this namespace's rows during a full backfill) fails DataQueryService: backfill preserves catalog rows the walk cannot see and reintroduces #1581. A fix needs to tell remote-only rows (lazy hydration) apart from rows whose data was deleted, for example by pruning rows whose metadata is gone locally only when the datastore does not use lazy hydration, or by a tombstone-aware pull.
• Separately, the S3/GCS extensions' pull never deletes local files (pullDeletes: false in the in-memory remote mirrors this), so in practice a peer's delete does not reach other repos' caches at all. That part lives in swamp-extensions.