fix(daemon): disclose drag ref refusals before dispatch

[xujiantop-crypto]

Summary

Closes #3183.

A drag refused by ref-frame admission before runtime binding now reports error.details.dispatched: "no", so stale refs are safe to retry. After Android blocking-dialog recovery, the refusal remains "unknown" because recovery already tapped and relaunched the app. The recovered drag failure also carries the recovery warning and preserves the ref-admission hint.

Three files change: the gesture admission boundary, the dispatch golden table, and production-router driver tests. The table covers drag admission and both drag/press aborts after Android recovery.

Validation

Tested source commit: 1d4bbd815bda4f3d50ba6422dfb800484dc99b71.

Linux validation passed with the repository's Node/pnpm setup:

• pnpm build, repository-wide pnpm format with a clean diff, pnpm depgraph affected, pnpm check:affected --run, and pnpm check:fallow --base origin/main.
• 17 dispatch driver cases and 974 related tests passed; all runnable affected gates passed.
• The warning regression fails on the previous PR head. Removing the pre-dispatch wrapper or disabling the recovery guard each fails its corresponding case (one failure each).

Upstream provider integration, coverage and native/device lanes await maintainer workflow approval. No live Apple or Android device was available locally. Fixtures exercise recovery routing with fake device facets, including tap/relaunch, but do not replace a live run. Published for review; merge readiness still requires device and CI results.

[cubic-dev-ai]

All reported issues were addressed across 3 files

<sub>Reply to a comment to ask cubic a question or push back. It learns from your replies.

Re-trigger cubic</sub>

[thymikee]

This PR is ready at 1d4bbd8. The drag ref refusal now reports dispatched "no" before any runtime bind, and the recovered refusal keeps the readiness warning. The single reported check passes, and there are no conflicts. The upstream integration and coverage lanes have not run on this fork PR, so a maintainer must approve those runs before merge.

Not blocking, and fine to take or leave: the same drag route has a second pre-dispatch refusal at interaction-gesture.ts#L98 (the bind refusal, and the swipe bind near line 172) that still reaches the wire as dispatched "unknown", while the touch route wraps it. The rule would be that every gesture failure before the bound runtime is called reports "no", applied once at dispatchGestureInteraction or in a follow-up issue. The warning concatenation at line 292 repeats the one at line 245, so one local helper could serve both. The press variant in interaction-dispatch-disclosure.test.ts#L282 sends a drag-shaped input that press ignores, and both variants share one session name.

I read the code path and did not run the tests or your mutation checks. I treated live device evidence as not needed, since the changed branch runs before any bind. If a maintainer wants it, a live iOS drag with expired refs that shows dispatched "no" would prove it.

The earlier review note on the recovered-refusal warning is fixed at this head: #3215 (comment)