feat: let one source carry several chats, and open them with a +

A source had exactly one live conversation, so the copilot could only ever
replace a chat, never add one: the trash button reset the source and the old
conversation was left orphaned. Working on two things at once meant losing one.

The tab bar now holds two kinds of tab. A primary tab is a source — it shows
whatever `web` or `project-7` currently points at, which is where background
delivery lands (notify, a finished async task, an inbound Telegram message) and
what a reset moves to a fresh row. A secondary tab, opened with `+`, is one
specific conversation: its source points elsewhere, so it is unreachable by
source name and is addressed by id throughout — REST, WebSocket, event
filtering. `POST /api/sessions/new` creates one without touching `sources`,
which is the whole difference from a reset; its agent and run-context still come
from the source, so an extra project tab is the coordinator with the project's
context. Project "Open chat" is untouched and still resumes the project's own.

The load-bearing half is in ChatHub: the input queue and the model pin are now
keyed by session, not by source. Two tabs on one source would otherwise
serialize into a single queue and a single turn, and share a `/model` pin — the
odd one out, since the security group was already per-session and persisted. The
source-taking methods survive as one-line resolvers, so Telegram, mobile and
cron are untouched. Because queues now grow with conversations rather than with
the handful of sources, a reset retires the queue it replaces instead of leaving
a consumer task parked forever.

Events are filtered per conversation, so anything a chat must see has to carry a
session id: `show_file_to_user`'s OpenFile and the security-group revalidation
were emitting untagged and would have reached nobody. A primary connection
additionally follows NewSession for its source, so a second window does not keep
talking to a conversation another window just reset.

Tabs can be renamed by double-click — `chat_sessions.title` existed and was dead
until now. An empty name stores NULL, so the box is also the undo.

CLAUDE.md

@@ -447,7 +447,13 @@ All extend `LightElement` from `web/lib/base.js` (Lit). `ChatSession` (`web/lib/
 
 **The chat is the home page.** `<app-copilot>` is a single persistent element with two layout modes driven by the route (`llm-page-change`): `mode="full"` on the home route (it fills the workspace — the conversation IS the landing page, with a welcome hero + prompt suggestions as its empty state) and `mode="dock"` on every other route (the classic resizable side panel). Same element ⇒ WS, tabs, scroll and drafts survive navigation; you watch files/projects update live while the conversation keeps going. Collapse only applies to the dock. The old dashboard content (hero, LLM stats charts, pending inbox, quick guide) lives on as the separate `#dashboard` page; the debug toggle moved to the Settings page.
 
-**The tab bar is server-side state; the selection is not.** Which conversations the copilot shows survives a reload through `chat_sessions.is_open` (owner table, additive via `ensure_column`) — `GET /api/sessions/open` restores them, `PUT /api/sessions/{id}/open` opens/closes one. It is deliberately *not* localStorage: that store is per-origin, so on a shared laptop one member's tabs would greet the next, and in the user's own encrypted file the set follows them across devices instead. **Which** tab is selected stays in `sessionStorage` (`copilot-active-tab`), because that one is per browser window — a shared value would have two windows fighting over it and turn every tab click into a write. Three consequences that are easy to get wrong: (a) `is_open` defaults to **0** and `chat_sessions::create` never sets it — every `/new` leaves its predecessor behind and every system-agent pass mints a row, so `DEFAULT 1` would restore a bar full of conversations nobody opened; only the copilot writes the column. (b) The General tab is never stored — it exists because the copilot exists. (c) A reset **moves** the flag: `provision_session(reset)` mints a new row, so `POST /api/sessions` returns the new id and the `new_session` event carries it, and `_bindTabSession` closes the old row as it opens the new one — leaving both would restore the source twice and let a later close clear the stale one. Restoring the selection happens *before* `super.connectedCallback()` (sessionStorage is synchronous) so the first paint doesn't fetch General and throw it away; the set arrives over the network and reconciles after, awaiting the base's initial connection so it never opens a second WS.
+**Two kinds of tab, and the difference is what a tab names.** A **primary** tab is a *source*: it shows whatever `web` / `project-7` currently points at (`sources.active_session_id`), which is also where background delivery lands — `notify`, a finished async task, an inbound Telegram message — and what a `/new` moves to a fresh row. At most one per source; a project's **Open chat** always lands on it and never mints a conversation (`provision_session(reset:false)`). A **secondary** tab is one specific conversation, opened with `+`: its source points elsewhere, so it is **unreachable by source name** and is addressed by id everywhere — REST, WebSocket, event filtering. Nothing is delivered to it from outside. `POST /api/sessions/new` creates one *without touching `sources`*, which is the entire difference from `POST /api/sessions` (a reset). Its agent and run-context still come from the source, so an extra project tab is the coordinator with the project's context.
+
+**The queue and the model pin are keyed by conversation, not by source** (`ChatHub.inboxes: HashMap<i64, ConversationInbox>`, `selected_clients: HashMap<i64, String>`). This is the load-bearing half: two tabs on one source would otherwise serialize into one queue and one turn, and share a `/model` pin — while the *security group* was already per-session and persisted, so the pin was the odd one out. The source-taking methods survive as one-line resolvers (`send_message` → `send_message_to_session`, and `_for_session` twins for context/cost/compact/mcp/model/cancel/resume/upload), so Telegram, mobile and cron are untouched. Cost of the rekey: queues now grow with conversations-talked-to-since-boot rather than with the four-or-five sources, so a reset **retires** the queue it replaces (`retire_inbox` → `ConversationInbox::close`, consumer breaks) instead of leaving a parked task forever.
+
+**Events are filtered per conversation** (`ge.session_id == Some(session_id)`), which is why anything a chat must see has to carry a session id — an untagged `GlobalEvent` now reaches nobody. Two emitters had to be fixed for exactly that: `show_file_to_user`'s `OpenFile` (the tool takes a `session_id` from `handler.session_id` via the interface-tools builder) and `revalidate_security_groups`, which now returns `(session_id, source, group)`. The inbox lifecycle events (`Approval*`/`Clarification*`/`Elicitation*`) stay the deliberate exception and go to every connection, since they carry ids only and drive the sidebar badge. A **primary** WS connection additionally follows `NewSession` for its source — re-binding `session_id` and its handler mid-loop — so a second window doesn't keep talking to a conversation another window just reset; a session-addressed one ignores it, having been pinned on purpose.
+
+**The tab bar is server-side state; the selection is not.** Which conversations the copilot shows survives a reload through `chat_sessions.is_open` (owner table, additive via `ensure_column`) — `GET /api/sessions/open` restores them (computing `primary` per row, since only `sources` knows), `PUT /api/sessions/{id}/open` opens/closes one, `PUT /api/sessions/{id}/title` renames one (`title` predated all this and was dead; an empty title stores `NULL`, so the rename box is also the undo). It is deliberately *not* localStorage: that store is per-origin, so on a shared laptop one member's tabs would greet the next, and in the user's own encrypted file the set follows them across devices instead. **Which** tab is selected stays in `sessionStorage` (`copilot-active-tab`), because that one is per browser window — a shared value would have two windows fighting over it and turn every tab click into a write. Three consequences that are easy to get wrong: (a) `is_open` defaults to **0** and `chat_sessions::create` never sets it — every `/new` leaves its predecessor behind and every system-agent pass mints a row, so `DEFAULT 1` would restore a bar full of conversations nobody opened; only the copilot writes the column. (b) The General tab is never stored — it exists because the copilot exists. (c) A reset **moves** the flag: `provision_session(reset)` mints a new row, so `POST /api/sessions` returns the new id and the `new_session` event carries it, and `_bindTabSession` closes the old row as it opens the new one — leaving both would restore the source twice and let a later close clear the stale one. Restoring the selection happens *before* `super.connectedCallback()` (sessionStorage is synchronous) so the first paint doesn't fetch General and throw it away; the set arrives over the network and reconciles after, awaiting the base's initial connection so it never opens a second WS.
 
 **Theme** (`web/css/variables.css`): warm "paper" palette (terracotta accent, light by default, warm-charcoal dark), generous radius (`--radius-sm/md/lg`), 16px-base chat type, WCAG-fixed contrasts, global `:focus-visible` ring and `prefers-reduced-motion` support. Everything consumes CSS variables — never hardcode a hex in a component stylesheet.