Workspace SQLite previews: explicit refresh and primary-key snapshot comparisons

[John-Ryan21337]

Club's database observatory can compare row snapshots using primary-key metadata. I am preparing a separate incremental adoption draft on project previews #114, independent of discovery issue #105.

The proposed port retains the existing fixed read-only snapshot worker, size/deadline/path and connection guards. It will return bounded typed primary-key identifiers only when complete, visible key values are safe to match. The UI compares successive explicit refreshes and can offer a separately explicit bounded refresh toggle. Truncated, masked, missing-key or ambiguous snapshots must not be presented as proven row changes. Differences describe observed snapshots, not a database audit log or proof of insert/delete operations.

No arbitrary SQL, global application-state database access, provider changes or user database testing. Synthetic SQLite and browser regressions, fresh independent review and final media/gates will accompany the fork draft.

[John-Ryan21337]

The bounded incremental implementation is available as draft Club PR #118, exact e3b5090889ee265d20d7f690e25c6d3ac46ec6f9, based on project SQLite preview #114 (4ae938a5021313e68a537d3a33ab59e285302486). It compares complete, unmasked previews with typed primary-key metadata and adds an explicit ten-second refresh toggle, off by default. Comparison reports displayed values, not a database audit log or complete database equality; Stop prevents future reads but does not cancel an accepted read.

Independent backend/helper/UI reviews and synthetic regressions passed. Final local validation: 4,128 repository tests with 6 existing skips, 333 Chromium tests, all type checks, formatting/lint, then the forced desktop build. English/Japanese limits, before/after images and an inspected 7.36-second synthetic recording are linked in the draft. No user database or account was accessed. Global application-state database access remains a separate feature.