Conversation memory layer: persist households/scenarios across turns

Motivation

Today, every turn is a one-shot. If a user says "For a single earner, £45,000, in Scotland, what's the marginal rate at £60k?" and then asks a follow-up "What if they were married?", the agent has to re-derive the household from the conversation transcript, often imperfectly.

This kills comparative conversations — the killer feature of a tax/benefits chatbot. The user can't iteratively build up a scenario; they have to restate the full household in every turn.

Goal

Persist a structured active scenario across turns within a conversation:

{
  "household": {
    "earners": [{"employment_income": 45000, "marital_status": "single"}],
    "children": 0,
    "country": "Scotland",
    "year": 2025
  },
  "reform": null,
  "comparison_baseline": "current_law"
}

The agent reads from and writes to this slot every turn. Follow-up questions like "What if they were married?" mutate marital_status and re-run, instead of re-extracting the entire household from scrollback.

Scope sketch (for discussion before implementation)

1. Backend: add an active_scenario field to the conversation (server-side state, persisted alongside messages in Supabase). New tool update_scenario(patch) for the agent to mutate it. New tool get_scenario() exposes the current state.
2. System prompt: tell the agent to read active_scenario at the top of every turn and call update_scenario whenever the user introduces or modifies household/reform parameters. Default policy: ambiguous changes get a Plan-mode-style clarifying question.
3. Frontend: subtle "Active scenario: single earner, £45k, Scotland" pill above the input chrome with an X to clear. Click → modal showing the structured state, with a "reset scenario" button.
4. Conversation save/load: round-trip active_scenario through the conversation document so it survives reloads and sharing.

Open questions

• Granularity: scenario per conversation, or per message? Likely per-conversation, with the agent able to fork it.
• Display: how much of the scenario to show in the pill (one-line summary) vs. modal (full structure)?
• Conflict with Plan mode: Plan mode asks clarifying questions before tools run; scenario memory wants the agent to use existing state. Probably composable but worth a careful look.
• Vs. typed tools (PR #55): typed tools already accept structured household + reform args; this issue is about persisting them across calls, not just typing them.

Why this is the next big lever

The chat-box UX is now saturated (10 features shipped in the last 24h). The next leap in user value comes from making conversations actually compositional — "like the household I described 3 messages ago, but bump UC by 10%" should just work.

Related: depends on / composes with #81 typed reform tools (typed-args make the scenario easier to express), and benefits from #85 reform recipes (recipes inform what to memoize).

Suggested next step

This is bigger than the recent batch — recommend a short design doc / discussion before implementation. Tag this as needs-design and discuss in PR form before code.

Start with the conversation document and message persistence, the typed tools in issue #81, and the Supabase save/load path described here; then review the system-prompt and frontend scope. Done means a design decision covers scenario ownership, mutation and reset behavior, Plan mode interaction, display, and round-tripping before implementation begins.