Start the confirmation Android hands back, so an update can install

Pressing INSTALL closed the application, installed nothing and said nothing. That
is two independent faults in one method, either of which breaks it on its own,
and they hid each other: the first kills the process before the second can be
observed, and the second is silent by construction.

The pending intent handed to commit was implicit — an action string with no
component behind it. A mutable pending intent may not wrap one of those from API
34, and this head targets 36, so every current phone threw IllegalArgumentException
before commit was reached. Nothing caught it, so it left the command handler,
passed the dispatcher and took the process with it. That is the closing.

Below 34, where it did not throw, it still installed nothing. An application
holding REQUEST_INSTALL_PACKAGES rather than the privileged INSTALL_PACKAGES gets
no verdict back from a commit: what the platform answers first is
STATUS_PENDING_USER_ACTION, carrying the activity that draws the dialogue in
EXTRA_INTENT for the application to start. Android does not draw it on its own.
The comment here asserted the opposite — that a pending intent is required whether
or not anything listens, and that nothing needed to — so no receiver was ever
written, and the session was written, committed and left staged forever.

So there is a receiver now, not exported because the only sender is this
application's own commit, and the intent naming it is explicit, which is the same
change that stops the throw. Sessions are abandoned when anything fails, since one
created and neither committed nor abandoned stays staged against a per-application
cap — a repeating fault would have started failing at CreateSession instead, which
is the same bug wearing a completely unrelated face.

The reporting is the part worth keeping even after the cause is gone. Where
applying ends the process an exception has nowhere to go; where it does not, which
is this head's whole shape, it goes out through the dispatcher. RestartNowAsync now
answers the way CheckNowAsync already did, and the regression test asserts the
absence of a throw rather than the presence of one.

ADR 0014 rule 6 gets the correction in place: "asks Android to ask" is one step
longer than it reads. Check 17.5 needed no rewording — it asks for the installer
appearing by name, which is exactly the thing that never happened — so what it
gets instead is the two symptoms named, because both present as a dead button. It
is the only thing in the project that can catch either, and it plainly was never
run against a real pair of builds.

Note for whoever takes the next nightly: a broken updater cannot install its own
fix. The phone is running the code this commit replaces, so the first build
carrying it has to be sideloaded by hand; the ones after that install normally.

Compile-verified and manifest-verified — the receiver reaches the generated
manifest — and 321 tests pass. Not run on a device, which is what 17.5 is for.

docs/adr/0014-android-updates.md

@@ -84,6 +84,18 @@ losing the local cache, the outbox and the device key.
    turned this application on in the unknown-sources screen. Two deliberate answers, neither to a screen
    DodoSSH controls.
 
+   ◆ "Asks Android to ask" is one step longer than it sounds, and reading it as one step is why this
+   installed nothing at all from the day it shipped until 2026-08-05. An application holding only
+   `REQUEST_INSTALL_PACKAGES` gets no verdict back from committing a session: what the platform returns
+   first is `STATUS_PENDING_USER_ACTION`, carrying the confirmation activity in `Intent.EXTRA_INTENT` for
+   the application to start. **Android does not draw the dialogue on its own.** The commit succeeded, the
+   session staged, and nobody was ever asked anything. The receiver that starts it is
+   `InstallSessionReceiver`; the intent naming it has to be explicit, since a mutable pending intent
+   wrapping an implicit one is refused outright from API 34. Check 17.5 asks for exactly the right thing
+   — "Android's own installer appears naming the package" — so nothing needed rewording; it wants an
+   older build installed and a newer one published to run at all, and on the evidence it was never run
+   against a real pair.
+
 7. **Applying does not end the process, and the shell had to learn that.** On Windows, applying replaces
    the files and restarts, so the shell disposes the vault first — that is what zeroes the identity keys,
    the vault keys and the cache key. On Android the install is a *request* and the answer may be no, so

docs/manual-checks.md

@@ -2091,6 +2091,14 @@ around being broken. An `INSTALL_FAILED_UPDATE_INCOMPATIBLE` means the two build
 keys — on the nightly channel that means the committed keystore changed, and on the release channel it means
 the wrong keystore was used.
 
+◆ Two failures worth naming separately, because both look like "the button does nothing" and neither is a
+signing problem. **The application closes when INSTALL is pressed** — that is an exception escaping the
+command handler, and the message it should have shown is now the Failed line on this screen. **Nothing
+happens at all, and the application carries on** — Android was asked to install and nobody started the
+confirmation it handed back; see `InstallSessionReceiver` and the ◆ note in ADR 0014 rule 6. This check is
+the only thing in the project that can catch either, which is the argument for running it on a real pair of
+builds rather than reasoning about it.
+
 ### 17.6 Declining leaves a working session · **the one that would be missed**
 
 Repeat 17.5 to the point where Android's installer is on screen, with a terminal open and the vault