feat: add a one-shot test cycle to the macOS install harness

`test` chains up -> run -> status -> down, which is the loop you actually want
when verifying a clean install. Three things make it more than a convenience
wrapper:

* It refuses to start against an existing account. A reused home is not a clean
  install, so testing one silently would defeat the harness.
* It tears the account down from an EXIT/INT trap armed the moment the account
  exists, so a failed run — or a Ctrl-C mid-install — still leaves the machine
  clean. BB_TEST_KEEP=1 opts out to poke at a failure.
* Its verdict is stricter than the installer's. install.sh exits 0 when it
  finishes but `doctor` reports unmet prerequisites, so "the installer
  succeeded" is not a useful assertion; `test` fails if the install fails, if
  bot-bottle never reached the new user's PATH, or if doctor is unhappy. That
  meant giving cmd_status a real exit status instead of swallowing doctor's.

Also fixes two bugs in `run`'s installer staging, by removing the staging
entirely and feeding install.sh in on stdin:

* `mktemp /tmp/bb-install.XXXXXX.sh` did not do what it looks like. BSD mktemp
  only substitutes trailing Xs, so every run wrote the *same* predictable path,
  as root, mode 644, in a world-writable directory.
* The cleanup only ran on the normal and failure returns, so an interrupted run
  leaked the file.

Piping on stdin sidesteps both: root opens the redirect before sudo drops
privileges, so the mode-700 home that motivated the staging is a non-issue,
there is no file to leak, and `sh -s` matches the documented `curl … | sh`
shape more closely than executing a staged copy did.

The command-level `exit 1`s become `return 1` so the steps compose under the
trap, and the "next, run this" hints are suppressed inside `test`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WEfZZhakx13bxTfXcZCoS5

docs/research/testing-clean-install-on-macos.md

@@ -213,6 +213,35 @@ headlessly (so a PR is verifiable before it lands) and lets the installer run
 the footprint analysis above — the reset is just user deletion because
 everything `install.sh` writes is user-home-local.
 
+`test` chains `up → run → status → down` into the one-shot cycle you normally
+want:
+
+```sh
+sudo ./scripts/macos-install-test.sh test
+```
+
+It refuses to start against an existing account (a reused home is not a clean
+install), and it tears the account down from an `EXIT`/`INT` trap armed the
+moment the account exists, so a failed or Ctrl-C'd run still leaves the machine
+clean. Its verdict is deliberately stricter than the installer's own: note that
+`install.sh` exits **0** when it finishes but `doctor` reports unmet
+prerequisites, so "the installer succeeded" is not the assertion — `test` fails
+if the install fails, if `bot-bottle` never reached the new user's `PATH`, or if
+`doctor` is unhappy. `BB_TEST_KEEP=1` skips the teardown to poke at a failure.
+
+### What a fresh account actually inherits
+
+Expect the first honest run on a developer Mac to fail at the *Python* gate,
+and expect that to be correct. A new account's `PATH` is just `/etc/paths`
+(`/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin`),
+which notably does **not** include `/opt/homebrew/bin`. Homebrew's `shellenv`
+line lives in the *installing* user's `~/.zprofile` and is not inherited, so a
+throwaway user resolves `python3` to `/usr/bin/python3` — the Command Line
+Tools stub, still **3.9.6** on macOS 26 — and `install.sh` correctly dies on its
+`3.11+` requirement. Your own shell resolving `python3` to a 3.14 Homebrew
+build says nothing about what a new user sees; that gap is exactly what this
+harness exists to expose.
+
 ## Sources
 
 - [Apple Containers on macOS: technical comparison with Docker — The New Stack](https://thenewstack.io/apple-containers-on-macos-a-technical-comparison-with-docker/)