fix: one tool-set recipe per session, so a tool cannot vanish between rounds

Two "unknown tool (not in this turn's tool set)" failures, one disease: the
turn's tool set was rebuilt from a different recipe depending on which entry
point happened to drive it.

A sub-agent got `ask_user_clarification`, `execute_subtask` and `activate_tools`
and nothing else — while `agents/common/tools.md` and every reporting agent's
prompt tell it to register its output with `update_scratchpad`. The child could
see the scratchpad injected into its context but had no way to write to it. It
now gets the scratchpad and todos tools, on the parent's `scratchpad_sid`: one
blackboard per session, as the surrounding code already declared.

`show_file_to_user` was injected per message by the WS handler, while
`resume_session` and `resolve_pending_call` rebuilt the list with `execute_task`
alone. So approving a card, or reconnecting mid-turn, continued the *same*
conversation with the tool silently gone. There is now a single recipe,
`ChatHub::session_interface_tools`, used by all three paths and fed by a builder
the shell installs once through `Skald::set_interface_tools_builder`: the core
keeps owning the tool, the shell keeps owning the policy of who gets it —
Telegram still does not, since it cannot act on OpenFile.

crates/plugin-telegram-bot/src/lib.rs

@@ -61,6 +61,11 @@ mod tools;
 /// check and the registration id can never drift apart.
 pub(crate) const PLUGIN_ID: &str = "telegram";
 
+/// The chat source id this plugin owns. Exported so the shell can tell a
+/// plugin-driven conversation from an SPA one when it declares which interface
+/// tools a session gets (a Telegram client cannot act on `OpenFile`).
+pub const SOURCE: &str = "telegram";
+
 /// Injected as extra system context for every Telegram turn.
 /// Kept compact to minimise token overhead.
 pub(crate) const TELEGRAM_FORMAT_CONTEXT: &str = "\