Chat: per-conversation model binding for multi-model Multi-Chat

[worsnoptr]

Implements the design proposed in #1173 — see that issue for the full rationale, UX mock, and discussion of the pane-binding alternative. Opening as a draft so the design conversation in the issue can proceed independently of code review; happy to adjust (field name, UX details, or switch to pane-binding) based on how that discussion goes.

Summary

• DConversation.userLlmId?: DLLMId — optional pinned model, resolved at execution time as pin ?? primaryChat domain default.
• getConversationChatLLMId(conversationId): validated pin or default; broken pins (model removed, or chat imported from an install with different services) silently degrade to the default, mirroring llmsResolveDomainModel's broken-assignment semantics.
• _handleExecute reads it instead of getChatLLMId() — one swap covers send, regenerate, retry, ReAct, and Multi-Chat broadcast (which already dispatches per conversation, so per-pane models fall out with no changes to the broadcast code itself). Beam's seed (beamOpen/beamImportRays) resolves per-conversation too.
• Utility flows (autotitle, fastUtil, codeApply, imageCaption) are untouched — they use the separate domain accessors.
• UX: model selector gains a "Pin model to this chat" / "Unpin · follow app default" entry; selecting a model edits the pin when pinned, the app default otherwise (zero behavior change until you pin). Each pane's title overlay now shows its bound model — outlined chip + 📌 when pinned, dimmed italic when following the default — so non-focused panes' models stay visible for side-by-side comparison.
• Persistence: optional field, no store version bump; duplicateDConversation copies the pin so branches keep their model; export carries it and import round-trips it (chats.converters).

Tested

• Single-pane, no pin: byte-identical behavior to before (verified via the send/regenerate/ReAct paths reading the same resolved model as getChatLLMId() would return).
• Pin / unpin / re-pin via the selector menu; broken-pin degradation (delete the pinned service, confirm fallback to default).
• Duplicate/branch carries the pin; export → import round-trip.
• 4-pane broadcast with four different models across all Bedrock dispatch paths (Converse, Invoke-Anthropic, Mantle Chat Completions, Mantle Responses) — verified each pane continues multi-turn on its own model and the per-model tool state (e.g. a Responses-only model's Web Search toggle) stays scoped to its own pane.
• tsc --noEmit, eslint, and next build all clean.

[vercel]

@worsnoptr is attempting to deploy a commit to the Token Fabrics Pro Team on Vercel.

A member of the Team first needs to authorize it.

[enricoros]

Thanks for opening this as a draft - DConversation.userLlmId is the right first move. To make it land cleanly: (1) keep the field; (2) route all chat model resolution through one function (chat pin > persona default > global fallback) instead of reading the pin at call sites - that mirrors how our hosted branch already works, and it is the difference between merging cleanly and fighting every rebase; (3) degrade silently when a pinned model disappears (fall back, never error); (4) leave the utility model domains (title/fast) alone. Reshape to that and review follows quickly.