Function resolve_agent_id 

pub(crate) fn resolve_agent_id(
    store: &Store,
    slug_or_id: &str,
) -> Result<String, String>

Resolve slug_or_id to a canonical db_agents.id.

Tried in order, first hit wins:

1. db_agents by slug — the persisted row. Fails closed when two rows share the slug (#3500), so an ambiguous slug falls through rather than resolving to an arbitrary winner.
2. db_agents by id — idempotent passthrough. Phases land in sequence, so a caller may hold a value that is already resolved; requiring each one to know which it has would defeat the point of a shared resolver.
3. The named-agent registry — a live agent with no db_agents row yet, which is the common case (launching an agent does not create one). Also fails closed on a colliding slug (#3480).

Err means “no agent” or “more than one agent”. They are deliberately not distinguished yet: both of the underlying lookups already collapse ambiguity into “not found”, and surfacing Ambiguous separately is a user-facing error-message decision the spec (§4) flags as needing UX input rather than a choice to make here. Nothing about this function’s shape prevents adding it later.