Merge branch 'claude/pipeline-curl-not-found-97e70f'

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