The paste confirmation is hard to find after "Read this reply"

Problem

Found on the device test of #88. After tapping Read this reply, the confirmation appears but takes hunting for.

The box is a six-row textarea, and #paste-confirm renders directly beneath it. On a phone the reader has usually scrolled so the textarea and the button fill the viewport, so what appears is below the fold — and the honest failure mode is tapping the button and seeing nothing happen at all.

The reader reported it as "slightly hard to find", not as a blocker, which is why it did not hold up #88.

Why it is worth fixing

This surface exists to satisfy ADR 0007 · C3 — no silent overwrite. A confirmation the reader has to go looking for is weaker than one they meet, and the failure is asymmetric: somebody who does not find it may tap Read this reply again rather than scroll, which rebuilds the same plan and still shows them nothing.

It also lands hardest on the reader this whole feature is for. Someone using the assistant bridge is likely doing so because typing and fine scrolling are costly.

Options

• Move focus to the confirmation heading once it opens, which also announces it to a screen reader. Cheapest, and probably sufficient on its own.
• scrollIntoView({ block: "nearest" }) on the confirmation. Careful: ADR 0001 rules out yanking the page around somebody mid-dictation, so this should only fire on an explicit tap, which it would.
• Shrink or collapse the textarea once a reply has been read, so the confirmation rises into view without the page moving.
• Put the summary line above the textarea rather than below it.

The first two compose and are the obvious starting point.

Acceptance criteria

1. After Read this reply succeeds, the confirmation is visible without the reader scrolling, on a phone-sized viewport.
2. Focus moves to it, so a screen reader announces that something happened.
3. Nothing scrolls or moves focus on page load, or on any path the reader did not initiate (ADR 0001).
4. A refused reply — where there is no confirmation to show — still announces its message.

Start at the implementation of Read this reply and the #paste-confirm element described in the issue. Check the existing behavior for successful and refused replies, then verify the acceptance criteria on a phone-sized viewport and with a screen reader, including that page-load and non-user-initiated paths do not move focus or scroll.