Make the bound chat one mechanism: a type supplies its describer, skill and options #3741

Overview

A play is edited through a chat bound to it: the chat pins the play and the play-authoring skill and opens on a message the system writes. That is built for plays only. This issue turns it into one mechanism any type can take part in, with the play as its first case and no change in what a play's chat does, so that schemas and saved queries can use it next.

Problem Statement

• create_play_edit_chat is specific to plays end to end: the service, the gRPC method, the Tauri command, the dev-proxy route, the frontend store call and the viewer's Edit button.
• A second type would mean a second copy of each.
• The opening message's content, the pinned skill and the options are fixed in code for plays, with nowhere for another type to supply its own.

Proposed Solution

• One operation, "open a chat bound to this node", that takes any node of a type that takes part and creates the pinned chat with its opening message.
• A type takes part by supplying three things: a describer (the node in plain language, from stored data only, no model call), the skill to pin, and the options, with the explain option always first.
• The play edit chat is restated on it: describer from the rules' required descriptions, skill play authoring, options "Explain this play" and the five kinds of change. Behaviour for a play is unchanged from A play's Edit chat: describe the play first, let the user ask about it, and route a reply with the message it answers #3738.
• The frontend has one call and one way for a viewer to offer the chat.

Documentation

• ADR-100 §1 to §4 - the mechanism, what a type supplies, explaining first and writing nothing, describing and confirming before a change
• ADR-090 §3 to §5 - the play edit chat, pins, and routing in a pinned chat
• ADR-088 - chats and message nodes
• Updates: architecture/ai-chat-node.md where it describes the play edit chat; the CLI reference if a command is added

Architecture Impact

Implements ADR-100 §1 and §2, which extends ADR-090. The note is on nodespace-docs main.

Acceptance Criteria

• One service operation, one RPC and one frontend call open a chat bound to a node; the play-specific ones are removed, not kept beside it
• A type that supplies a describer, a skill and options gets a bound chat with no other code; a type that supplies none is refused with a clear error
• The opening message is produced with no model call and appears with no model loaded
• The explain option is first for every type, by construction
• A play's chat behaves exactly as after A play's Edit chat: describe the play first, let the user ask about it, and route a reply with the message it answers #3738: same description, same options, same routing
• Tests cover: a type that takes part, a type that does not, and the play case end to end
• Code passes bun run quality:fix and bun run test:changed

Technical Specifications

Reference Files

• packages/daemon/src/services/play_edit_chat.rs, local_agent_service.rs
• packages/proto/proto/local_agent_service.proto
• packages/desktop-app/app-lib/src/commands/local_agent.rs, packages/dev-tools/src/dev-proxy.ts
• packages/desktop-app/src/lib/services/tauri-commands.ts, stores/ai-chats.svelte.ts, components/viewers/play-node-viewer.svelte

Implementation Details

• Resolve what a type supplies through the type registry, not by comparing node_type with a literal.
• No compatibility path for the old play-only call: replace it.
• A new CLI input or output needs its skill-guidance wording in the same change.

Dependencies

• A play's Edit chat: describe the play first, let the user ask about it, and route a reply with the message it answers #3738 (fixes the play chat's opening message, options and routing; this builds on the fixed behaviour)

Non-Goals

• The schema and query chats themselves
• Making any other type read-only outside its chat