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/skald-core/src/session/handler/mod.rs

@@ -366,6 +366,22 @@ impl ChatSessionHandler {
         self.fs.load()
     }
 
+    /// The swappable fs **cell**, not a snapshot: a tool built from it follows a
+    /// §6 remount instead of pinning the membership it saw at build time.
+    pub fn shared_fs(&self) -> SharedFs {
+        self.fs.clone()
+    }
+
+    /// The owner's encrypted pool (`{userid}.db`).
+    pub fn owner_pool(&self) -> &Arc<SqlitePool> {
+        &self.db
+    }
+
+    /// The registry pool (`system.db`) — shared memory, registry tables.
+    pub fn shared_pool(&self) -> &Arc<SqlitePool> {
+        &self.shared_pool
+    }
+
     /// Override the session used for scratchpad reads/writes.
     /// Called by the cron runner for async tasks so they share the parent's scratchpad.
     pub fn set_scratchpad_session_id(&self, id: i64) {