feat: bind compose agents to capsets

[eetoc]

Summary

• add capset_ids to agent-compose.yml agent specs and v2 AgentSpec
• persist normalized capsets onto project-managed agent definitions and scheduler loaders
• inject capability gateway env/tags and write the MPI catalog for project RunAgent sessions

Fixes #39

Verification

• go test ./pkg/compose ./pkg/agentcompose -run 'Capset|Capability|ProjectServiceApplyProjectPersistsAgentCapsetIDs|RunServiceRunAgentInjectsProjectAgentCapabilities' -count=1\n- go test ./pkg/compose ./pkg/agentcompose ./proto/agentcompose/v2 ./proto/agentcompose/v2/agentcomposev2connect -count=1\n- task lint\n- task build\n\ntask test was not run to completion because we intentionally avoided the E2E suite during final verification.

[eetoc]

Real regression test completed on the rebased branch (2ba2f61).

Environment exercised:

• Runtime driver: Docker
• Guest image: agent-compose-guest:latest
• LLM model: kimi-k2.6
• OctoBus built and started from /root/OctoBus
• agent-compose started from this PR branch

Verified flow:

1. Started a real OctoBus daemon, imported the calculator example service, created the calculator-test instance, and created the dev capset.
2. Verified OctoBus directly via Connect RPC: calculator.v1.CalculatorService/Add returned result=42.
3. Started agent-compose with Docker runtime, runtime LLM facade, and capability proxy configured for Docker guest access.
4. Applied an agent-compose.yml whose agent has capset_ids: ["dev"].
5. Verified the real Docker-backed project session contains:
   • session tag capset=dev
   • env CAP_GRPC_TARGET
   • secret env CAP_TOKEN
   • runtime/mpi/catalog.md with the dev catalog
   • catalog entries for /calculator.v1.CalculatorService/Add and /calculator.v1.CalculatorService/Subtract
   • routing metadata x-octobus-capset=dev / x-octobus-instance=calculator-test
6. Used the session CAP_TOKEN through the agent-compose capability proxy and successfully called calculator Add via gRPC; result was 42.
7. Ran a real Claude-provider agent with kimi-k2.6; the run succeeded and returned:
   {"ok":true,"method":"/calculator.v1.CalculatorService/Add","capset":"dev"}

Additional note:

• Codex provider reached the daemon LLM facade, but this backend did not work with the Codex openai_responses wire path in this setup. With chat_completions enabled, Codex failed with the expected protocol bridge error from openai_responses to openai_chat. This appears separate from this PR's capset binding behavior.

Merge recommendation: LGTM after CI completes successfully.

[eetoc]

Adding the agent-compose.yml used for the real capset binding regression test, so the verification is reproducible without relying only on the prose summary.

name: capset-regression

agents:
  reviewer:
    provider: claude
    model: ${ANTHROPIC_MODEL}
    image: agent-compose-guest:latest
    driver:
      docker: {}
    capset_ids:
      - dev
    system_prompt: |
      Use the injected capability catalog from the runtime MPI context when a capability is available.
      For the calculator capability, call /calculator.v1.CalculatorService/Add through CAP_GRPC_TARGET
      with the catalog-provided x-octobus-capset and x-octobus-instance metadata.

Runtime environment values such as LLM/Anthropic API keys, OctoBus tokens, and generated CAP_TOKEN values were intentionally not included in the comment. The important PR-specific assertion is that applying this compose file preserves capset_ids: ["dev"] on the managed agent and binds that capset into the real Docker-backed run session.