Let bots manage their hooks, with the user confirming what widens them

Bots get list_hooks, pause_hook and delete_hook, which act directly since
they only take away. A new hook, or a new name, brief or filter, or
switching a paused one back on, goes through propose_hook: it stores a
hook_proposals row and puts a [hook-proposal:ID] card in the reply, which
the user it was proposed to confirms or rejects. The card is read from
what Confirm saves, with the bot's reason labelled as its own; confirming
checks everything again and saves through the Hooks modal's helpers. A
new hook's URL is shown on the card once, to the user only, never in the
outcome the bot is told. What calls a hook, its computers and its signing
are never proposed. Only chat replies propose, and a hook call's own run
gets no hook tools, so a caller's payload can't reach them.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

src/utils/link-computer-refs.test.ts

@@ -3,6 +3,7 @@ import botRef from "./bot-ref";
 import workspaceRef from "./workspace-ref";
 import computerRef from "./computer-ref";
 import linkComputerRefs from "./link-computer-refs";
+import hookProposalRef from "./hook-proposal-ref";
 import proposalRef from "./proposal-ref";
 import takeOverRef from "./take-over-ref";
 
@@ -27,6 +28,12 @@ describe("linkComputerRefs", () => {
         );
     });
 
+    test("links hook proposals apart from extension proposals", () => {
+        expect(
+            linkComputerRefs({ text: `${hookProposalRef({ id: 4 })} and ${proposalRef({ id: 4 })}` }),
+        ).toBe("[hook proposal 4](#hook-proposal-4) and [proposal 4](#proposal-4)");
+    });
+
     test("links take-over requests", () => {
         expect(
             linkComputerRefs({