refactor: expose ToolContext on ToolCall instead of a code_mode flag

[frostming]

What changed and why

ToolCall carried a single code_mode flag copied from the ToolContext. Hooks now get the whole context instead, so they can read code_mode and any other per-call information without new fields being added to ToolCall each time.

• ToolCall.context: ToolContext | None replaces ToolCall.code_mode. It defaults to None and is excluded from repr and equality, so logging a call does not dump the tape and state. dataclasses.replace in hook argument rewrites keeps it.
• ToolExecutor passes the call's ToolContext when building the ToolCall.
• The builtin spill hook checks call.context.code_mode to leave run_code results structured (behavior unchanged).
• ToolContext is imported only for type checking in bub.hooks.interception, since bub.tools imports that module.

Impacted modules

bub.hooks.interception, bub.tools, bub.builtin.hook_impl; tools docs (en/zh-cn).

Breaking for hook authors: plugins reading call.code_mode must switch to call.context is not None and call.context.code_mode.

Verification

• uv run ruff check .
• uv run mypy src
• uv run pytest -q — 573 passed, 1 skipped
• The executor test now asserts that hooks receive the same ToolContext object passed to the executor.
• Docs build not run.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bub	46052b1	Commit Preview URL Branch Preview URL	Oct 01 2026, 02:48 AM