feat: custom orchestrator gateways via YAML config (v0.0.10) - #19

Summary

• Add Orchestrator::Custom(String) variant — unknown orchestrator names now resolve to custom gateways defined in ~/.orca/config.yaml
• Add YAML config loading (OrcaConfig/GatewayConfig) with {text}, {worker}, {channel}, {target}, {thread} template placeholders
• Env vars still override YAML values (fully backwards compatible)
• Custom gateway delivery via sh -c in the wake module, with expand_template() helper
• Dynamic CLI validation: accepts builtin orchestrators + any configured gateway name
• Gateways with a reply template require --reply-channel at spawn time (like openclaw)
• Added config.example.yaml with Hermes gateway example
• Updated README.md and SETUP.md with configuration docs

Backwards Compatibility

• All existing orchestrators (cc, cx, cu, openclaw, none) work exactly as before
• Env vars (ORCA_MAX_DEPTH, ORCA_MAX_WORKERS, ORCA_WATCHDOG_QUIET_SECS) still override
• No config.yaml file needed — defaults remain the same when absent
• Existing state.json entries deserialize correctly

Example Usage

# ~/.orca/config.yaml
gateways:
  hermes:
    wake: 'hermes chat -q "{text}"'
    reply: 'hermes chat -q "Use the send_message tool to send to {channel}: {text}"'

orca spawn "do task" -b cc --orchestrator hermes --spawned-by self --reply-channel matrix-room --reply-to room-id

Test plan

• cargo fmt --check passes
• cargo clippy -- -D warnings passes
• All 660 tests pass (cargo nextest run)
• Pre-commit hooks pass

🤖 Generated with Claude Code