Subscriptions: reject capped results before replacing complete state #165

Problem

A capped query result is adopted as the complete standing-query set. This can silently omit rows or retract valid rows, and the initial WebSocket response reports that it is not truncated.

Evidence

Source: 5c1f313379a5cb2995a43a66ddba0b5cc9798b7f (inspected 2026-10-03). These are source findings; the acceptance scenarios below still need implementation and execution.

• src/protocol/handler.rs:3991: Result capping sets QueryResult.truncated.
• src/protocol/subscription/reevaluate.rs:76: Refresh consumes rows and replaces current without checking truncated.
• src/protocol/rest/handlers/ws.rs:901: The subscription response hardcodes truncated: false.

Acceptance criteria

• Reject truncated/incomplete initial snapshots with an explicit error; never advertise a capped set as complete.
• On an incomplete refresh preserve the last complete state and emit an explicit reset-required/error state, with documented recovery once the result fits again.
• Use cap=3 and 10 rows to cover registration, crossing the cap after a valid snapshot and dropping below it again over a real socket.
• Do not disable result limits to hide the failure. Complete bounded transport is tracked in Wire v2: ordered revisions, stream reset and complete delta delivery #174; uncapped-small delivery must pass Performance: baseline and mandatory pre-PR regression pipeline #163.

Delivery

Plan item: S05. R1 - Safety + perf/e2e gates.

Dependencies / related work: #163.