feat: opt-in event logging for Stitch tool call

[davideast]

Adds an opt-in capture system that records every Stitch MCP tool call made through stitch-mcp tool or the proxy. Off by default, zero overhead and zero on-disk writes when off; enable with STITCH_MCP_LOG=1.

Output goes to .stitch-mcp/log/:

• events.jsonl — one JSON envelope per event (call.requested + call.completed | call.failed)
• blobs/<2-char-shard>/<sha256>.<ext> — content-addressed payloads (args, raw responses, structured content, HTML, screenshots, theme, design system)

Motivation

We have no record of what users actually generate through stitch-mcp — args, prompts, returned screen IDs, asset bytes, or failures. That makes debugging "this generation came back wrong" effectively impossible after the fact, since Stitch's downloadUrls expire fast. The capture is opt-in and local-only, so it doesn't change behavior for anyone not setting the env var.

What's logged

Tool kind	Examples	Captured
generative	generate_screen_from_text, edit_screens, generate_variants	args, structured content, eagerly fetched HTML + screenshot bytes, theme, design system, parent/sibling screen relationships
read	get_screen, list_screens, list_projects, get_project, create_project	args, full result blob, extracted returned_project_ids / returned_screen_ids
unknown	anything else (e.g. list_design_systems)	args, full result blob — so a new tool added upstream is never silently invisible
failure	any isError: true response, transport-level throws, or empty generative responses	full raw response stored as raw_blob, error_text preserved verbatim

Eager fetch matters: Stitch's downloadUrls expire — if we only logged URLs, the bytes would be gone by the time anyone tried to replay.

Architecture

• src/lib/log/blob-store/ — content-addressed put/fetch/has/get with sha256 dedup; never throws (Result type per the typed-service-contract pattern)
• src/lib/log/capture/ — turns (request, response, duration) into events
• src/lib/log/append.ts — validate envelope + atomic appendFile of one line
• src/commands/tool/steps/LogExecuteToolStep.ts — swaps in for ExecuteToolStep when log is on; reaches into the SDK client for the raw envelope and captures even on transport-level throws (timeouts, network errors)
• src/commands/proxy/LoggingCallToolHandler.ts — overrides the SDK proxy's tools/call handler with a capture-wrapped variant; never propagates capture failures to the MCP client

Bug bash

Branch was bug-bashed end-to-end against live Stitch with scripts/bug-bash-logging.sh. Two findings led to follow-up commits on this branch:

1. Unclassified tools were silently skipped. kindOf() returned null and capture bailed early, so list_design_systems produced zero events. Fixed in 0f25bdc: kindOf() now returns 'unknown' and the handler logs args + raw response.
2. Read-tool capture only recorded what was requested, not what was returned. list_screens was logged with just projectId — no record of which screens came back. Fixed in 0f25bdc: read calls now store the full response as result_blob plus walk the response for name: "projects/<id>" / "screens/<id>" patterns to populate returned_project_ids / returned_screen_ids.

Final bug-bash run: 12 events / 30 blobs / 6 paired traces / 0 orphans across create_project → generate_screen_from_text → edit_screens → generate_variants (3 children captured with parent linkage) → list_screens → list_design_systems.

Side finding (unrelated to this PR)

• list_screens returns empty {} from Stitch even after the project has multiple screens. Surfaced by the bug-bash; logged here for follow-up but not addressed in this PR.

Test plan

• bun test — 559 pass, 6 skip, 0 fail (74 new tests for log/blob-store/capture/append + handlers)
• npx tsc --noEmit — zero new errors
• bun run build — clean
• Live bug-bash with STITCH_MCP_LOG=1 — all six tool calls captured with expected fields populated, asset URLs fetched before expiry, failure path captured raw response + error text
• Disk growth measured: ~600 bytes per identical read call (full sha256 dedup), ~5 KB per distinct read call, ~100 KB
  per generative call. 100 generative calls ≈ 10 MB. Sha256 dedup means repeat queries are nearly free. No automatic
  rotation/TTL — recommend follow-up if long sessions become a concern.