feat(composer): move Conversation Mode to the composer, delete the drawer

[philmerrell]

Step 5 of docs/specs/customize-surface.md. The settings drawer and its icon are gone. −2293 / +461.

⚠️ The plan was wrong about Conversation Modes

The spec had Modes retired in step 6 as "a strictly weaker Agent", on the premise they were dormant (untouched since PR #411). They are not. Measured against the prod account:

Enabled modes in prod	1 — Guided Learning (Socratic tutoring)
Sessions using it	81
July / Aug / Sept	1 / 20 / 60 — and September is 12 days old

Deleting the drawer as written would have removed a growing, pedagogically-meaningful feature outright.

This is the second time "git history says dormant" has misled on this epic — step 3's thinking param was the inverse, declared in curated-models.ts and absent from the deployed records. Check the data in the environment that matters.

Where Mode went

Skills and Tools left for Customize because they're global. Mode couldn't follow: it applies to this conversation, and putting it on a global page would recreate the exact scope lie this epic exists to fix.

So it went the other way — into the composer, beside the model and effort controls. Those three are the same question: how should this conversation run. The old passive chip (which could display an active mode but never select one) is replaced by a picker that does both, with "None" carrying the chip's dismiss role. It renders nothing until an admin authors a mode, so most deployments see no new control.

That also reframes step 6 as reconsider, not execute: retiring Modes is hard to justify against growing use, and the migration isn't clean — a Mode applies to the conversation you're in; an Agent is a separate thing you start a chat with.

⚠️ Latent bug found while verifying, fixed here

The session page hydrates the active mode twice on load — provisionally (before session metadata arrives) and then for real. The provisional call claimed the session id, so the clobber guard in hydrateFromSession rejected the real hydration.

Not cosmetic: chat-request.service sends selected_prompt_id from activePromptId(), so after any reload the mode silently stopped being applied to every later turn while the stored preference still said it was on. On prod that's every Guided Learning user who reloaded mid-conversation.

The provisional call now passes claim: false. A deliberate "None" still claims, so stale metadata can't undo it — that edge has its own test. Fixed here rather than deferred because this change promotes the control to a first-class affordance; shipping it more prominently while knowing it silently drops would be worse than leaving it alone.

Open question, resolved

No composer pointer to Customize. The sidenav entry is the path — always visible, one click, the same shape Claude uses. Adding one would have reintroduced an icon to replace the one this removes.

Verification

• ng test — 2805 passed; 14 new (8 picker, 6 hydration regression including the "None isn't clobbered" edge).
• tsc --noEmit clean.
• Browser-verified against a real backend: no settings icon, no drawer, picker silent with zero modes. Then seeded a temporary mode in dev and exercised the whole path — trigger shows "Mode" → select → named + accented + correct aria-label → "None" returns it → selection persists to session preferences ({"selectedPromptId":"zz-picker-test"}) → survives a reload (the bug above, before and after). Test record deleted and local .env restored afterwards; dev is back to zero modes.

Note DYNAMODB_SYSTEM_PROMPTS_TABLE_NAME is unset in the local .env, so the repository disables itself and returns [] silently — worth adding to .env.example, not done here.

🤖 Generated with Claude Code