Proposal: pilot-storage-backend-interface

The reference implementation maintains two storage engines (SQLite via records.js/search.js, Postgres via postgres-records.js/postgres-search.js) dispatched by isPostgresStorageBackend() branches scattered across the server. A full inventory (tmp/workstreams/storage-backend-pilot-design-2026-06-18.md) classified all 187 such branches: 153 are drifttoremove (the same conceptual storage operation implemented twice inline in shared orchestration), 21 are adapterselectionkeep (the legitimate backend-selection points, already the right pattern), and 14 are backendspecifickeep (honest dialect logic that is clearer kept backend-specific: SQLite WAL retry, Postgres FOR UPDATE locks, sqlite-vec vs pgvector).

Shared orchestration code SHALL invoke a storage operation that has been migrated to the StorageBackend interface through a single typed interface method, with no isPostgresStorageBackend() branch in the orchestration path. Each backend SHALL provide one adapter that satisfies the interface method, keeping dialect-specific query logic (placeholder syntax, deleted boolean representation, JSON normalization) inside the adapter rather than in shared code. A migrated operation SHALL be exercised by a dual-backend conformance harness that runs the production code path against both the SQLite adapter and a real Postgres adapter and asserts identical observable results, so that divergence between the two backends becomes a test failure rather than a silent production difference.