Screenshot readback design: which routes hold a bound captureScreenshot, and the admission story for --expect-screenshot-diff #4509

Parent context: #4318 group C. The 11-08 direction asked for this design issue before the readback half of #4297 merges (the baseline half shipped in #4338).

The problem

--expect-screenshot-diff on press/click needs a bound captureScreenshot on the dispatch device. Today only the screenshot route binds one (screenshot-runtime-binding.ts); the daemon touch routes build their backend through createInteractionBackend without it, so the flag is a silent no-op on every shipped surface. The 11-08 rule: every route that admits the flag must hold a bound captureScreenshot, admitted through runtime operation admission; otherwise the request must refuse before dispatch.

Options for the decision

1. Admit a capture operation on touch routes. The interaction runtime facts gain a screenshot-capture operation; a request with expectScreenshotDiff admits it like any runtime operation, and the interaction backend binds the admitted capture. Cross-route operation admission may interact with fix(settle): compare post-action trees in one view across every route #4500's settle unification.
2. Refuse on routes without a bound capture. A typed pre-dispatch refusal (screenshot-capture-unavailable) on touch routes when the flag is set; the flag then works only where the admission can prove a capture. Smaller, but the flag stops working wherever binding does not exist yet.

Related decisions wanted

• The any-one-pixel changed rule reports incidental animation as a change (review thread r4497036508): is a threshold wanted, or is any-change the honest contract for keypads where one pixel IS the reaction?
• The --no-record-style recording interaction for a screenshot-bracketed plan step (from feat(interaction): multi-ref press plan lowered through the ordinary press lane #4296's plan work), if the readback composes with multi-ref plans.

State of the code on #4297's head

The evidence lane itself is defect-free as of 7471601's successor commits: nothing after a resolved dispatch throws out of the lane (decode/read/import/cleanup failures yield no evidence), the after-frame settle honors the request signal, and both full-resolution frames decode in the codec worker. The corruption test the review asked for pins the delivered-tap case. Live runs (iOS simulator, Android emulator) follow once the decision lands and the flag actually reports on a shipped surface.