Intent declared

The body failed validation — including a window above the 168-hour ceiling, which is refused rather than clamped

Missing, invalid or expired token

TWO types share this status and they are NOT interchangeable — branch on
type, not on the status:

• .../errors/forbidden — the opaque refusal. Byte-identical for an
  insufficient scope, a cross-tenant attempt and an account that is not
  reachable in this tenant, because the endpoint must not answer 'does
  this account exist?'.
• .../errors/impersonation-operation-forbidden — the caller is acting
  under a support-access impersonation session. A DISTINCT cause,
  deliberately not collapsed into the opaque refusal: the operator holds
  admin.tenant.user.update and is inside the tenant boundary, so naming
  it discloses nothing about the account. Declaring an intent authorises
  a federated identity to bind to an existing account — a takeover that
  outlives the consent window — so it is refused as the handler's FIRST
  statement, before the opaque refusal can be reached. The refusal binds
  on SaaS deployments only (PRD §148): SaaS is the only place ANKATech
  operates a tenant belonging to somebody else.

The TENANT does not exist. Never returned for an unknown account.

A conflict. TWO types share this status and they are NOT interchangeable —
branch on type, not on the status:

• federated-link-target-already-bound — the account already carries a
  federated subject. Remedy: unlink it, then declare.
• federated-link-intent-already-declared — a LIVE authorization is already
  outstanding. Remedy: revoke it, then declare. A live one is refused rather
  than replaced, so a repeated request cannot silently extend the window it
  was granted for. A LAPSED authorization is NOT refused: it is cleared in
  the same transaction as the new one and the declaration proceeds. That is
  not a relaxation — a lapsed row grants nothing (the bind branch refuses it
  exactly as it refuses no intent at all), so replacing it extends nothing.

A structural refusal. The type member distinguishes the cause, and a
consumer should branch on it rather than on this status:

• federated-link-target-protected — the break-glass administrator;
  structurally excluded, no configuration permits it.
• federated-link-last-local-account — the target is the last account
  that can still sign in locally; linking it would leave no way in if
  the provider became unavailable. The target is EXCLUDED from that
  count: it is still local and ACTIVE when the guard runs, so counting
  it would admit exactly the case the guard exists to refuse.
• federated-link-provider-not-eligible — ONE opaque type across every
  ineligibility cause; this endpoint's scope does not entitle the caller
  to enumerate providers. Eligibility resolves the tenant's EFFECTIVE
  provider — its own override when it has one, otherwise the inherited
  deployment default — so a tenant that inherits the deployment default
  does not need an override of its own in order to declare a link.
• federated-link-target-not-active — the target account is not active.
• federated-link-claim-mismatch — the declared address is not the
  target account's own, so the intent could never be consumed.

Unexpected error