deprovision a member's linux account when the platform account goes

Implements docs/deprovision-os-account.md. Until now deleteUserHandler removed the row, cascaded the
database, and left the entire Linux side running — measured on production on 2026-08-12: working login
shell, healthy postgres container, 454M of data, uid queued for the next useradd to reissue along with
everything still owned by it.

The load-bearing rule from the spec: sever the data from the uid BEFORE releasing the uid, and if
severing fails, do not release. A failed deprovision is not a broken account, it is a trap for whoever
is created next.

Sequence: disable-linger, terminate-user, reap-and-prove, chown -R, userdel (never -r).

  reap    terminate-user is not a barrier. Production measured a three-hour-old `/bin/zsh -i` surviving
          it AND the removal of /run/user/<uid>. So: pkill, bounded wait, pkill -9, bounded wait, and a
          final count that must be zero or the account is not released.
  chown   fixes the uid and subuid halves in one pass — it rewrites every file it walks whatever owned
          it. The range is still captured first, because userdel removes the /etc/subuid entry and after
          that nothing on the machine remembers what it was. It is returned on every path including the
          failures, and logged as the exact assert-uid-free.sh command line.

Two guards the spec did not ask for, both pure and unit-tested:

  guardDeletable    ensureOsUser's adoption rule backwards. Deletable only if the passwd home is the one
                    the platform would have confined, and uid >= 1000. Without it `userdel root` is one
                    bad users.osUser away and nothing else in the sequence would object.
  guardMemberTree   the tree must resolve to a direct child of DATA_PATH. The email reaches join() from a
                    database row and the result is the argument to a recursive chown.

chown runs with -h. Measured here that `chown -R` already declines to follow a symlink out of the tree and
re-owns the link itself, but the argv should say so rather than rest on traversal semantics — and
re-owning links is what makes `find -uid` (lstat) a meaningful check afterwards.

destroy exists, has no call site, and is chown-then-delete-as-the-service-user rather than sudo rm -rf, so
a recursive root delete built from a database column does not exist in this codebase.

deleteUserHandler now runs this FIRST and refuses to delete the row if it fails: the row is what remembers
there is anything to clean up, so deleting it first makes a failure unrecoverable through the UI.

NOT YET RUN AGAINST A REAL ACCOUNT. Only the pure guards have tests. The five-step validation is in the
doc; it needs the production host, a shell left open, and a container writing as a non-root user — the two
cases the quiet path passes vacuously.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

TODO.md

@@ -14,13 +14,14 @@ the owner's OS user and can never be granted. Indirection there really is accide
 
 ## Multi-user
 
-- [ ] **`deprovisionOsAccount` does not exist, and deleting a member leaves their whole Linux side.**
-      `deleteUserHandler` removes the row and cascades the database; `userdel` never runs. Observed on the
-      production host on 2026-08-12: a member deleted through the UI kept a working login shell, a running
-      Postgres container and 454M of data, and their uid was free for the next `useradd` to reissue. Spec in
-      `docs/deprovision-os-account.md`. The ordering that matters: reap processes explicitly (`terminate-user`
-      does **not** reap a stale shell, and `userdel` fails while one lives), then `chown -R` to the service
-      user, then `userdel` — sever before release, and abort if the `chown` fails.
+- [ ] **`deprovisionOsAccount` is written but has never run against a real account.** Landed 2026-08-12 in
+      `os-user-deprovision.ts` and wired into `deleteUserHandler`, which now refuses to delete the row when
+      the Linux teardown fails — so a failure is retryable instead of forgotten. Only the pure guards
+      (`guardDeletable`, `guardMemberTree`, `parseSubUidEntry`) have tests; the reap loop, the `chown -R`
+      sever and `userdel` have been exercised by nobody. `docs/deprovision-os-account.md` → "What is still
+      unproven" has the five-step validation, and it has to happen on the production host with a throwaway
+      account that has **a shell left open** and **a container writing as a non-root user** — those are the
+      two cases the quiet path passes vacuously.
 
 - [ ] **The terminal replays terminal QUERIES, which get typed into the shell.** `sidecar/pty/sessions.mjs`
       replays the whole scrollback on attach; query sequences in the buffer get re-asked, xterm.js answers,