Function shared_token_rejection_outcome 

fn shared_token_rejection_outcome(
    status: StatusCode,
    agent_id: &str,
) -> AgentSyncOutcome

What to do when the SHARED account-level token itself (not a per-agent credential — that case is already handled by the invalidate-and-retry branch above) is rejected. 401 and 403 are NOT interchangeable here even though both satisfy is_credential_rejected:

• 401 (expired) → ReconnectSharedTokenExpired. Reconnecting is productive: the outer loop’s load_valid_token calls RefreshScheduler::ensure_fresh first, which can mint a genuinely new, accepted access token from the refresh_token before retrying.
• 403 (the agent-binding check rejected this account for agent_id) → AgentSyncOutcome::Ok (skip this agent this cycle, log a warning). MuxBusCredentials::is_valid() is purely expiry-based, so the still time-valid access token survives load_valid_token unchanged after a reconnect — and even a genuine refresh would mint a new token for the same binding, so nothing about tearing down and reconnecting the WS session can fix a binding mismatch. Treating it like a 401 anyway (the original extension of this function) churned the whole shared session through repeated reconnects with the identical rejected token, starving InjectAvailable delivery for every OTHER registered agent too — reagentx P1 on PR #2573. Matches this project’s pre-403-handling behavior for exactly this case (log-only, no reconnect); only the per-agent-credential branch above actually gained 403 recovery.