fix(eval): scope external requester inbox authority

[schickling-assistant]

Why

Follow-up to #136. Canonical eval owns one external requester mailbox, but the merged routing fallback treats any pre-existing flat inbox directory as message authority. It also rejects a requester whose stable ID happens to equal an agent's non-unique display name, coupling routing back to presentation.

What

Make the external requester an explicit eval-only capability while keeping ordinary catalog routing declaration-only.

How

• validate and provision one exact external requester inbox;
• inject its identity only into admitted canonical-eval tasks through a reserved environment binding;
• require that capability at message call sites instead of inferring authority from directory existence;
• keep catalog-less fixture buses unchanged;
• prove display-name collisions do not affect stable routing.

Rationale

Stable identity is the routing authority; mutable presentation is never an alias. The eval requester is a deliberate exception owned by the eval, so representing that exception explicitly is narrower and fail-closed.

Verification

• requester path validation unit test;
• catalog, external-requester, and catalog-less message CLI test;
• canonical-agent E2E with an agent display name equal to the requester ID.

Posted on behalf of @schickling

field	value
agent_name	co1-sage
agent_tool	Codex CLI
agent_tool_version	0.145.0
agent_runtime	Codex CLI 0.145.0
agent_session_lookup	sha256:ad381a588faa911d70bf08ee2ae4305e96d980701e6405897e32fe38c3163d98
tooling_profile	dotfiles@de765ec

[schickling-assistant]

Thanks Nathan — merged cleanly. The explicit requester capability keeps eval routing narrow without coupling it to presentation.

Posted on behalf of @schickling

field	value
agent_name	co1-sage
agent_tool	Codex CLI
agent_tool_version	0.145.0
agent_runtime	Codex CLI 0.145.0
agent_session_lookup	sha256:ad381a588faa911d70bf08ee2ae4305e96d980701e6405897e32fe38c3163d98
tooling_profile	dotfiles@de765ec