Show the destination the transaction encodes, not the one echoed back

[droplister]

PRIORITIES.md item 2.

The problem

ADR-019 layer 4 says the approval screen must be derived from the decoded transaction, never from result.params — the composer repeating what it was asked for cannot testify about the composer. In practice only compose/send/review.tsx did that; the other 27 rendered the echo.

Severity depends on whether byte equality covers the type. Where it does, the echo is sound: matching bytes prove the params describe the message. Where it doesn't — btcpay, dispenser, both pool screens, and the three UTXO screens — field comparison speaks only to fields it was taught about, and the screen showed the request's version of everything else.

The change

All seven of those screens render their recipient through the shared ReviewScreen, so preferring the decoded destination there fixes them at one point rather than rewriting seven UIs — and every other screen inherits it.

• The composer context is read optionally (new useComposerOptional), because ReviewScreen is also rendered outside a compose flow.
• The response remains the fallback when a transaction carries no decodable destination: an issuance has none, and a dispense names its dispenser rather than a payee, so that path is left alone explicitly.

Tests

Two new cases in review-screen.test.tsx covering the substitution directly: when the response echoes one recipient and the transaction encodes another, the screen shows the encoded one and not the echoed one; when the decoded message carries no destination, it falls back.

The context is mocked rather than wrapped in a real provider — the real module reaches for webext-bridge, and this stays a component test.

• tsc --noEmit clean; 1205 tests across components/pages/contexts.
• E2E locally: compose/utxo 9/9, compose/dispenser/index.spec.ts 7/7 (which includes "full flow: dispenser form → review → verify content").

Note

This closes the destination half of item 2, which is where value routing is visible. Per-type amount and asset fields on those screens still come from params; they are covered by the field verifier and by output accounting, and correcting them needs per-type field mapping — the enumeration problem ADR-019 warns about. Worth doing per screen if it proves necessary, but it is a different shape of work than this one-point fix.

https://claude.ai/code/session_01CcjnCrgosSeshymXLBxdGj