v2 2.0.16: todowrite state not persisted to project-todos store — client UI (OpenChamber) todo panel always empty #51396

Description

The v2 2.0.16 client-visible todo store is never populated with the agent's live todo state, so UI clients that read it (OpenChamber's right-sidebar todo panel, which uses GET/PUT <project>/todos) always show an empty list while the agent is actively working with todos. No error is surfaced anywhere — the channel is simply silently dead.

Steps to reproduce

1. Run opencode 2.0.16 (AppImage) with OpenChamber 2.0.0 as the UI.
2. Start a session where the agent maintains a todo list (any non-trivial task that uses the todo tool).
3. While the agent is working, open the OpenChamber right-sidebar todo panel.

Expected: the panel shows the current todo list (this worked in v1, where the store was populated and the UI rendered the list).
Actual: the panel is always empty. The panel itself works — editing todos directly in it persists fine; the store just never receives the agent's state.

Environment / OS

• OS: Garuda Linux (Arch-based), x86_64, kernel 6.x
• opencode: 2.0.16 (AppImage)
• UI: OpenChamber 2.0.0
• Also reproduced headlessly: no UI involved — the stores below are simply empty.

Evidence (audited on a live 2.0.16 install)

1. The v2 binary's compatibility shim lists todowrite in its compat list and injects the system message "The todowrite tool is no longer available and must not be called" — i.e., TodoWrite is not a real tool in v2.
2. The environment still executes todo operations internally (the agent can read/modify todos mid-session), but the state never reaches any client-visible store.
3. Full audit of every candidate store — all empty of todos:
   • opencode.db: project table, kv table (2 keys only), no *todo* tables;
   • zero message parts of type todo; session_pending 0 rows;
   • no todo files anywhere under the data dir.

Why it matters

Todo state is one of the primary channels users rely on to see what the agent is working on. In v2 that channel is silently dead. Same bug family as #51269 (v2 2.0.16 compat-shim regressions).

Expected

Todo state maintained during a v2 session is persisted to the project-todos store (or an equivalent client-readable store) so UIs like OpenChamber can display it, matching v1 behavior.

Duplicate check (per bot request)

• [FEATURE]: Project-level todo lists visible in GUI #18564 (project-level todos visible in the GUI): closely related user-facing goal; this issue explains why it can't work in v2 — the store is never populated. Not a duplicate; fixing this issue unblocks [FEATURE]: Project-level todo lists visible in GUI #18564.
• [FEATURE]: Add persistent todo list to prevent losing progress when context limits are reached #18071 (persistent todo state across sessions): overlaps in persistence, but this issue is about in-session state never reaching the client store at all. Not a duplicate.

Cross-reference

Complementary upstream issue filed at the UI repo the same day: openchamber/openchamber (todo-panel discoverability + synthetic-message/loop-visibility improvements) — that issue is the UI-visibility half, this one is the data-pipeline half.