Reject or preserve literal RefProxy semantics in remote subset wire #2187

Problem

The managed SQLite remote-subset wire accepts a literal RefProxy in an IR.Value, but projects it to {}. A predicate whose literal has reference identity then reaches the provider with different semantics. This is separate from PR #2134's query-identity and historical-owner repairs.

packages/db-sqlite-persistence-core/src/remote-subset-wire.ts calls projectWireValue for IR.Value.value. Its plain-record branch sees the proxy's empty enumerable shape and emits {}. The package's stated wire domain is values whose complete semantics survive transport; an opaque reference proxy does not meet that rule.

During PR #2134's real SQLite receiving attempt, a proxy captured through public Collection.createIndex reached this path, and the provider received {}. Object.is(originalProxy, projectedValue) was false. A row with the projected value therefore cannot establish ownership for the original literal-proxy demand. The attempted row-bearing upgrade witness was removed rather than counted as passing; the limitation is recorded in docs/contributing/oracle-reviews/pr-2134-identity-and-persisted-key.md.

Expected follow-up

Decide the wire contract for opaque literal values. A defensible default is to reject the request with RemoteSubsetWireValueError before coordinator or storage work, since cross-process transport cannot preserve the proxy's reference identity. Add a receiving oracle case using a proxy from the same public @tanstack/db package instance as Query Collection; compare admission, provider requests, and storage work. If the intended contract instead supports such literals, specify and test the identity-preserving representation first.

This issue does not block the primitive singleton-IN migration covered by PR #2134's real SQLite restart tests. It does block a claim that row-bearing historical literal-proxy ownership was migrated through the managed SQLite path.