Demo — capability delegation to sub-agent

[lthibault]

Verify that scoped capability delegation works correctly and that permission boundaries hold. The primary user-facing showcase is the TUI's AI tutor (#122) — this issue focuses on the underlying mechanism and its invariants.

The tutor child process (spawned via host.executor().runBytes(wasm)) receives a narrowed capability: it can call getState(), getLegalMoves(), and getFen() but NOT applyMove(). This is a fundamental object-capability operation that static WASI sandboxing cannot express.

Scaffold the consultant guest with ww init --template=rust guests/chess-consultant.

Acceptance criteria

• Consultant guest scaffolded with ww init and built with ww build
• Parent process spawns consultant as a child process
• Consultant receives narrowed capability (read-only board access)
• Consultant cannot call applyMove — RPC returns a permission error (not a silent failure)
• Capability attenuation is enforced at the RPC layer, not just by convention
• The capability chain is visible in logs (who delegated what to whom)
• Works for both the human-side tutor and any future AI-side consultant (symmetric mechanism)