close the comms channel, keep what was still open

The sidecar-app-store channel ran one night, from per-user Linux accounts to a
member's first agent turn, and is deleted now the work has landed. A spent
channel left in place gets read as current, which is worse than none.

Three things lived only in those docs and move to TODO.md rather than
disappearing: deprovisionOsAccount (observed on production — a deleted member
kept a shell, a running container and 454M of data, with their uid free to
reissue), the terminal replaying query sequences as keystrokes, and agent
sessions not being durable, which is one missing property behind three symptoms.
The deprovision spec itself already lives in docs/.

CLAUDE.md's section is rewritten from "here is the current channel" to how to
run one, since the answer to "which channels exist" is now none. What is worth
keeping is the protocol that emerged: numbered alternating files, parity as the
author, a reply even when there is nothing to say, and termination on a
checkable condition rather than on someone deciding it feels finished.

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

TODO.md

@@ -14,6 +14,25 @@ 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.
+
+- [ ] **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,
+      and the answers arrive as keystrokes. Visible to a member daily. Fix is to strip query sequences in
+      `appendBuffer`, so a replay reproduces output and never re-issues requests.
+
+- [ ] **Agent sessions are not durable, and it is one property behind three symptoms.** A sidecar restart
+      loses session identity, which is why `endTurnIfAgentIsGone` must skip sessions with no recorded
+      `userId`, why a stuck "generating" spinner survives until a reconnect, and why any crash in that process
+      is destructive rather than merely inconvenient. Fixing the three separately would miss that they are one
+      missing property.
+
 - [x] **No way to create a second account.** Fixed 2026-08-11 on `sidecar-app-store`: `POST /api/users`
       (`api/users/create-user.ts`, owner-gated) plus an Add-account form in
       Settings → User management. Created accounts are `status: 'Active'` — the column defaults to
@@ -57,7 +76,7 @@ the owner's OS user and can never be granted. Indirection there really is accide
 
 - [ ] **`pty`, `vault` and `opencode` receive no identity at all.** Every other sidecar validates
       `X-Officer-User`. The pty sidecar keys purely on a `sessionId` from the query string and its
-      `/_officer/sessions` endpoints list and kill *every* session on the box; vault and opencode take
+      `/_officer/sessions` endpoints list and kill _every_ session on the box; vault and opencode take
       no user argument. All three are covered today only because `terminal`, `vault` and the agent are
       owner-only capabilities — that is a correct outcome resting on the wrong layer, and it is the
       thing to fix first if any of them is ever granted.
@@ -67,7 +86,7 @@ the owner's OS user and can never be granted. Indirection there really is accide
       side is ready for members; the CalDAV server underneath is not.
 
 - [ ] **The music library is one global index.** `sidecar/music/indexer.ts` reads `HOME_DIR` and serves
-      every account from it. Favourites, playlists and now-playing *are* per-user. Deliberate for now
+      every account from it. Favourites, playlists and now-playing _are_ per-user. Deliberate for now
       (one household, one library) but worth stating rather than discovering.
 
 - [ ] **`markInterruptedJobs()` and `getOldestPendingJob()` are platform-wide.** The pipeline queue is a