bug(runtime-host): the judgement background session keeps the Matter and memory-index mutation tools the discovery boundary removed #6412

What happened

#6244 split the assistant heartbeat into two persistent background sessions: discovery and judgement. The assistant tool filter (packages/runtime-host/src/assistant/index-initiative/host.ts:60-64) still matches only the discovery session — store.get()?.discoverySession === sessionId — so the judgement session, registered as a background session (host.ts:54-56) and admitted by service.ts:123-130, receives the full assistant catalog: including the exact tool groups that #6256 removed from the discovery session (memory-index mutations, MatterAdopt, conversation-scoped Matter controls, worker-only Matter lifecycle tools, Bot-only and initiative-configuration tools — per the boundary summary on #6250).

For these tools the only constraint on the judgement session is prompt text, and the #6256 boundary's premise is precisely not to trust the prompt: proactive-matters/delegation.ts:232-234 guards MatterDelegate only against matter-worker recursion (store.forSession(call.sessionId)), so a judgement session — which is not a matter worker — passes and creates a delegation owned by an invisible background session; memory-network/host.ts:520+ validates MemoryIndexWrite only with the expectedRevision CAS, with no session-ownership guard at all. #6256's execution-time rejections are scoped to the discovery session, so they do not fire here.

Deterministic reproduction

The discovery-boundary.test.ts pattern applies directly: put a judgementSession id into the InitiativeStore (same write shape as two-stage.test.ts:111-123), then assert the judgement session's catalog excludes the boundary tools (or invoke MemoryIndexWrite as the judgement session and observe the write succeed). On main@ed3f91707 the assertion fails — the tools are present and the write is admitted; the probe chain (resolve → filterTools → visibleTools, service.ts:135-141 / 206-209) is wired in production via execution-composition.ts:1459-1473.

Suggested fix

Extend the session filter's matching set to cover the judgement session, excluding at least the tool groups in the #6256 verified boundary (Matter mutations, memory-index mutations, Bot-only and initiative-configuration tools); the discovery session's existing exclusion list stays as-is. A discovery-boundary-style catalog test for the judgement session locks it.

Note: #6253 introduces a stronger read-only allowlist mechanism for the discovery session; this issue is the complementary gap — the judgement session currently bypasses even the established #6256 exclusion set. If the maintainer prefers, the judgement scoping could ride #6253's session-scoped filterTools mechanism instead; either way the gap itself is independent of that PR.

Source

Found by an AI-assisted read-only audit (GLM-5.3-Flash via ZCode) over main@ed3f91707; the filter wiring, the delegation and memory-write guards, and the #6250/#6256 boundary scope were re-verified line by line before filing.