fix(feed): the mine's deadline never reached the transport; 60 s cut it off

The 2026-09 change raised MEMPALACE_FEED_MINE_TIMEOUT_MS to 300 000 and
raced it against client.callTool("mempalace_mine"). But callTool() had no
way to carry a deadline, so every call went out under the transport's
generic per-request timeout (MEMPALACE_MCP_TIMEOUT_MS, 60 000), which fired
first on every honest 60 s+ mine. Operators saw

    feed (tick) failed: mempalace remote request 'tools/call' failed:
    timed out after 60000ms

instead of the message the change had aimed at, and the 300 s was
unreachable. On stdio it was worse than noise: that transport kills the
server child on timeout, so the mine was actually aborted at 60 s.

callTool(name, args, { timeoutMs }) now passes a per-call deadline to both
transports; feedPalace() uses it for the mine. Plain calls keep the short
default — a query taking 60 s is still wedged. The Promise.race stays as the
liveness guard for a transport with its timeout disabled (0).

scripts/test-mcp-call-timeout.sh cuts RemoteMcpClient out of the shipped
file (as test-owed-withdrawal.sh does for the mailbox predicates), drives it
against a local JSON-RPC server that delays tools/call, and asserts: plain
call rejects at the generic deadline; the override outlives it; the override
is itself a deadline. Fails on the previous commit (2 of 6), passes here.
Vendored-copy delta noted in the header; protocol untouched, sync token
unchanged (check-mcp-client-sync.sh passes against pi-extensions).

extensions/pi/README.md

@@ -423,6 +423,9 @@ one — the long-lived server is only killed when a request genuinely stalls.
 
 - `MEMPALACE_MCP_TIMEOUT_MS` — tool-call/request timeout. Default `60000`.
   Kept short on purpose: a *query* taking this long is genuinely wedged.
+  The one call that is not a query — the feed's `mempalace_mine` — passes its
+  own deadline (`MEMPALACE_FEED_MINE_TIMEOUT_MS`) down to the transport per
+  call, so this default does not apply to it (since 2026-09-18; see below).
 - `MEMPALACE_MCP_INIT_TIMEOUT_MS` — `initialize` + `tools/list` handshake
   timeout. Default `300000`. Deliberately generous: a genuine first
   cold-open over virtiofs can legitimately take minutes, and killing a
@@ -489,6 +492,26 @@ exceeded five minutes. Check palace size and whether another writer (a
 host-side feeder, a scheduled `mine`) is holding the write lock, rather than
 raising the timeout again.
 
+### `feed (tick) failed: mempalace remote request 'tools/call' failed: timed out after 60000ms`
+
+Same event, different deadline — and the same reassurance: **nothing has been
+lost**, the mine continues server-side.
+
+This is what the previous message turned into after the 2026-09 change, and
+it exposed that the change was incomplete. The feed's five-minute deadline was
+only *raced* against the call; `callTool()` had no way to carry it, so the
+transport's generic per-request timeout (`MEMPALACE_MCP_TIMEOUT_MS`, 60 s)
+fired first on every honest 60 s+ mine, and the 300 s was unreachable. On the
+stdio transport this was worse than noise: a per-request timeout there kills the
+server child, so the mine really was aborted at 60 s.
+
+Fixed 2026-09-18: `callTool(name, args, { timeoutMs })` passes a per-call
+deadline to both transports and the feed uses it for the mine.
+`scripts/test-mcp-call-timeout.sh` pins the contract (a plain call still honours
+the short default; the override is honoured and is itself a deadline). Seeing
+this message on a fixed build means a mine exceeded *five* minutes — treat it as
+the previous section says.
+
 ## The `Type.Unsafe` gotcha
 
 Earlier versions of this extension registered every MCP tool with