Function relay_token 

pub(crate) async fn relay_token(
    source_agent: &str,
    store: &Arc<Store>,
    http: &Client,
) -> Option<RelayCredential>

Resolve the credential to relay as, preferring one bound to this specific sender over the shared account token — the same precedence the inbound path (cloud_subscriber::sync_agent_reactive) already uses, so a binding-enforced account behaves consistently in both directions.

None means the account isn’t logged in to muxbus at all, i.e. tier 4 doesn’t exist here.

store must be the one muxbus credentials actually live in — AppState::id_store, the same store CloudSubscriber::init_global and every muxbus.login/status/disconnect handler use. Passing the per-channel mstore finds nothing whenever the shared root resolves (the normal case), so tier 4 would silently never fire for a logged-in user (reagent #3023 P0). Note this deliberately does NOT follow AppState’s general steer toward identity_store for new muxbus call sites: the credentials are written to id_store, and reading from a store the writer doesn’t use would reintroduce the same bug whenever isolated_auth_enabled() redirects one but not the other.

Ordering matters. The shared account token is a purely local read, so it is checked FIRST: no credential means the account isn’t logged in, and there is nothing for a per-agent credential to be provisioned against. Doing it the other way round makes ensure_agent_credential attempt a cloud provisioning round trip (POST /agents/provision) on a logged-out instance — once per failed local inject, i.e. on the hot path of every message to an unknown agent.

Returns the account too, read from the same shared token: the carry gate needs the directory this send goes into, and reading the account separately would let a sign-in in between pair one account’s token with another’s directory (Codex P2 on #3994).