Let the recovery code be copied, and give the phone a clipboard to copy to

Both screens had made the code selectable and both said why: a person who cannot
get it out of the box photographs the screen, and a screenshot is a worse home
for it than a clipboard. This finishes that argument. Selecting 64 characters of
letter-spaced monospace with a thumb is the version of "possible" people give up
on halfway — and on the phone the screen blocks screenshots, so the honest
remaining options were retyping it or losing it.

It is the one secret this application deliberately offers to a clipboard, and the
contrast with the keychain's copy is the whole argument rather than an
inconsistency. There, copying the private half is refused outright, because
installing a key means pasting the public one and the private one has no business
leaving the vault. Here there is no better route: the code exists for one screen,
is stored nowhere, and has to reach a password manager. The clipboard is the
intended destination rather than a way round the design.

The sentence afterwards matters as much as the copy, and is asserted: a clipboard
is a staging post, this screen is the only place the code exists, and the next
thing copied replaces it. Somebody who copies and does nothing has not saved it.

The phone had no clipboard delegate at all — the desktop passed one and this head
passed null — so COPY PUBLIC KEY on the keychain answered "this machine has no
clipboard" on a device that plainly has one. Nothing about that was platform
shaped: Android has a clipboard and Avalonia surfaces it through the same
TopLevel. Wiring it fixes that copy too.

The test fixture built its shell without a clipboard, which modelled the bug
rather than the product, so it has one now and the public-key test asserts what
lands there instead of the refusal. The refusal keeps its own test, on a shell
built without one, because the view model reads the delegate's absence rather
than an empty result — and because a button that silently does nothing on this
screen is worse than one that refuses.

docs/manual-checks.md

@@ -1188,7 +1188,23 @@ directly instead of `Classes="... secret"`. `PasswordChar` is what the screen dr
 what the keyboard is told, and only the second one keeps a passphrase out of the IME's learning
 dictionary. A box showing dots with a suggestion strip over it is the worst case, not a cosmetic one.
 
-### 10.2 The keyboard does not cover the box being typed into
+### 10.2 COPY CODE actually copies, on both heads
+
+Enrol a fresh profile. On the recovery-code screen, press **COPY CODE**, then paste somewhere — another
+app on the phone, a text editor on the desktop.
+
+**Pass:** the whole code arrives, and the line under the button says to put it in a password manager now.
+
+**Failure means:** if the phone says *this machine has no clipboard*, the delegate is not being passed to
+`MainWindowViewModel` again — the phone shipped for a while with none, so every copy on that head said
+exactly that on a device that plainly has one. If nothing is said at all, the button silently no-opped,
+which on this screen is worse than refusing: somebody who believes the code is on their clipboard will not
+write it down, and it is shown once.
+
+Worth pasting somewhere you can see all of it. The code is the only thing standing between a forgotten
+passphrase and an unrecoverable vault, and a truncated copy fails silently months later.
+
+### 10.3 The keyboard does not cover the box being typed into
 
 The same box: with the keyboard up, the passphrase box and the UNLOCK button under it are both visible.
 Repeat on each of the five boxes that take a secret — lock screen, both enrollment boxes, the connect
@@ -1201,7 +1217,7 @@ password on HOSTS, and the connect password on FILES.
 `WindowSoftInputMode` has been dropped from the activity and the platform is panning the window instead of
 resizing it — which, for a window whose whole content is one native view, pans by nothing useful.
 
-### 10.3 Nothing is stranded when the keyboard closes
+### 10.4 Nothing is stranded when the keyboard closes
 
 Dismiss the keyboard with back or the down-chevron from each of those screens.
 
@@ -1211,7 +1227,7 @@ bottom and no scroll position left part way down.
 **Failure means:** the inset is being applied but not cleared — the closed state is not being read from the
 event, or the margin is only ever added to.
 
-### 10.4 Rotating with the keyboard up
+### 10.5 Rotating with the keyboard up
 
 Focus a passphrase box, then turn the phone sideways.