feat(v2): configure tool availability per session

[kitlangton]

Summary

V2 needs a public API and generated SDK surface for enabling or disabling tools for a specific Session. Today tool definitions are filtered by the selected Agent’s configured permissions, but neither the Session API nor the prompt API can apply Session-specific tool availability.

V1 behavior

V1 accepted a tool map on session.prompt(...):

await client.session.prompt({
  sessionID,
  tools: {
    bash: false,
    write: false,
  },
})

The implementation translated those entries into permission rules and persisted them on the Session. This provided the capability, but the contract was misleading: a field on one prompt mutated durable Session configuration. The field is now deprecated in V1.

V2 gap

• PromptInput.Prompt contains only text and attachments.
• Session.Info has no Session-specific tool or permission configuration.
• ToolRegistry.materialize(...) receives only the selected Agent’s permission rules.
• SDK consumers cannot create a restricted Session without defining a separate Agent in configuration.

Desired behavior

Provide an explicit Session-scoped API for tool availability, exposed through Protocol and generated clients. The common SDK use case should be straightforward:

await client.session.configure({
  sessionID,
  tools: {
    bash: false,
    write: false,
  },
})

The exact endpoint and representation need design. In particular, decide:

1. Whether this is a tool-specific allow/deny map or a Session permission ruleset.
2. How Session rules compose with Agent permissions and built-in tool permission actions.
3. Whether changes are durable Session configuration, scoped to one admitted prompt, or whether both concepts are needed.
4. Whether consumers can inspect the effective tool catalog after composition.

Non-goal

Do not restore V1’s implicit behavior where sending a prompt silently mutates persistent Session configuration.