usage panel: verified for one account, not for two

the owner confirmed it live the same day. what that leaves untested is the
half the cache exists for — a second login, the tabs, a stored row surviving
a switch — so the docs now say which half is proven instead of claiming
neither is.

also records the bug the first deploy found, since the doc had asserted the
degradation that turned out to be broken.

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

TODO.md

@@ -447,27 +447,21 @@ outside the example's new README:
 
 ## Waiting on the owner to run it
 
-- [ ] **The AI usage panel has never run.** Landed 2026-08-18. Click the harness pill in the chat composer
-      and it shows Claude Code's own usage display — limits with countdowns, tokens by day and by model —
-      with one tab per Anthropic account, so a login you have switched away from still answers.
+- [ ] **The AI usage panel works for one account; the multi-account half is unproven.** Landed and verified
+      live 2026-08-18 — click the harness pill in the chat composer and it shows Claude Code's own usage
+      display, limits with countdowns, tokens by day and by model.
 
-      **Two things must happen before it does anything**: `bun db:push` (it adds `ai_provider_usage`) and
-      `pm2 restart officer officer-claude-code`. Neither has been run. Without the push the panel opens and
-      shows the signed-in account with no tabs, which is the designed degradation rather than a failure.
+      What is NOT proven is the reason it was built: a second Anthropic login, the account tabs, and a
+      stored row surviving a switch. **Group C of `docs/ai-usage-panel.md`** is that, and test 10 is the one
+      most likely to be wrong — a refresh must not overwrite an account it could not measure, and that
+      failure is silent.
 
-      **`docs/ai-usage-panel.md` is the checklist** — sixteen ordered tests in five groups. Group C is the
-      feature: sign in as the second account and confirm the first one keeps its numbers and its countdown.
-      Test 10 is the one most likely to be wrong — a refresh must not overwrite an account it could not
-      measure, and that failure is silent.
+      Deliberately deferred rather than forgotten: the owner switches accounts when the work needs it, and
+      the worst case is one wrong tab. Run Group C the first time a second login lands on this machine.
 
-      Safe to leave untested. Everything is read-only except one fire-and-forget upsert at turn end, and the
-      pill was already an inert label before this. The one thing worth watching is `pm2 logs officer` during
-      a turn: the snapshot is `void`ed and swallows its own errors, so a persistent failure shows up only
-      there and as a row that never updates.
-
-      Shipped alongside it and also unexercised: the model dropdown no longer renders the literal string
-      `claude-code` for a chat that named no tier. That half needs `officer-claude-code` restarted, not just
-      `officer` — the parser in the sidecar is what emits it.
+      Also unexercised: the model dropdown no longer renders the literal string `claude-code` for a chat
+      that named no tier. Needs `officer-claude-code` restarted, not just `officer` — the parser in the
+      sidecar is what emits it.
 
 - [ ] **Plan mode is live and has never been exercised.** Landed `1b811dfa` on 2026-08-17; all three
       processes were restarted the same evening, so the code IS running. Not one part of it has been used: