hod 0.1.10 — Codex workers get real role boundaries

Herdr workers running Claude Code get their role boundaries from settings.<role>.json profiles. Workers running Codex had nothing equivalent — a reviewer or impl started with --kind codex was bounded by wording alone.

The principle: a role is defined by the promise the controller may trust, not by the mechanism. Each CLI enforces that promise with its strongest layer — Claude with tool deny rules, Codex with its OS sandbox — and the new references/role-boundaries.md maps all three roles to both CLIs, naming the honest gaps on each side instead of pretending parity.

reviewer    -s read-only -c features.multi_agent=false          # fresh session
controller  -s workspace-write --ask-for-approval never \
            -c sandbox_workspace_write.network_access=true \
            -c features.multi_agent=false
impl        -s workspace-write --ask-for-approval never \
            -c sandbox_workspace_write.network_access=true \
            -c 'sandbox_workspace_write.writable_roots=["<abs-repo>/.git"]'

hod settings list now prints these beside the Claude profiles.

Every claim was verified empirically on codex-cli 0.145.0/0.146.0 (macOS), including two findings worth knowing:

• .git is protected inside workspace-write — commits fail until the repo's .git is listed in writable_roots. The impl flags above handle it.
• The sandbox network rule also covers Herdr's own Unix socket, so a Codex controller cannot be sandbox-locked and still drive Herdr. Its no-edit promise is wording-level — symmetric with Claude's controller, which leaves Bash open.

Upgrade: hod update

Tests: 105 hod, green on macOS and Linux.