API: Auth

Reads only the `pp_rt` httpOnly cookie, rotates it exactly like `/auth/refresh`, and returns the token response together with the currently available shell data. An optional `org_id` switches the organization after the server re-checks active membership. Cloud responses may include `billing` and `usage`; on-prem responses may include `license`. Shell sections are optional so a temporarily unavailable section does not invalidate an otherwise valid session. The response is never cacheable.

No request body: the refresh token is read from the `pp_rt` httpOnly cookie. Always clears the cookie; a missing/unknown token still yields 204. A present `Origin` header must be in the allowlist, otherwise 403.

Atomically consumes state, exchanges the code with its encrypted PKCE verifier, and validates issuer, audience, signature, expiry, nonce, verified email, exact domain policy and controlled membership/JIT policy. Success sets only the httpOnly refresh cookie and redirects to the SPA; no token is placed in the URL.

Resolves exactly one enabled organization from an exact email domain (or an explicit org_id), then creates a short-lived one-time state, nonce and S256 PKCE verifier. The verifier is encrypted at rest. No credential is returned to the SPA; authorization_url points to the IdP.

Always returns 204 regardless of whether the account exists (prevents user enumeration). If the account exists, an email with a one-hour reset link is sent; requesting a new token invalidates previous unused ones.

Consumes the one-time token: on success all refresh tokens of the user are revoked (every session is logged out). An unknown, used or expired token yields 422 with message "invalid or expired token".

The refresh token is read EXCLUSIVELY from the `pp_rt` httpOnly cookie (send with `credentials: include`). An optional `org_id` selects a new organization context; the server derives the user from the refresh token and re-checks an active membership before minting the new org claim. Omitting the body preserves the refresh token's current org and remains backwards-compatible. On success the cookie is rotated (new Set-Cookie); on an invalid/reused token the cookie is cleared and 401 is returned (reuse also revokes all of the user's sessions). A present `Origin` header must be in the allowlist (CORS_ORIGINS + APP_BASE_URL), otherwise 403.

Continuation of the 409 domain_has_org answer of `/auth/register/verify` («Это другая компания»). Accepts the same email+code or link token plus an optional company_note, consumes the verification and registers the user and organization through the ordinary path — but with a pending_review subscription instead of a trial: event ingestion is blocked immediately and the cabinet is read-only (403 trial_pending_review) until a manual review activates the account (email promise: within one business day). The applicant is logged in right away (201 token response). Code defects — and calling this endpoint without an actual domain conflict — yield the same uniform 422 as `/auth/register/verify` (the verification is left untouched in the no-conflict case).

Continuation of the 409 domain_has_org answer of `/auth/register/verify`. Accepts the same email+code or link token, consumes the verification and emails the owner of the most recent organization on the domain a request to invite the applicant (Settings → Team link included). No user or organization is created — membership only appears through the ordinary invite flow. Every code defect — and calling this endpoint when the domain rule would not fire — yields the same uniform 422 as `/auth/register/verify`; in the no-conflict case the verification is left untouched so a normal verify still works.

Always answers 202 whether or not a pending verification exists (anti-enumeration). When one exists, a fresh code and link token are issued and the previous ones stop working. Rate limited to 1 request per minute per email on top of the shared per-IP limit.

Trial-first companion of `/auth/register`. Accepts either the email plus the six-digit code from the confirmation email, or the opaque link token from the emailed URL. Every defect — unknown email, expired or already used verification, more than 10 wrong code attempts, wrong code — yields the same 422 so pending signups cannot be enumerated. Success creates the user, the organization and (per catalog policy) its trialing subscription in one transaction, and returns the same body a legacy 201 registration would, plus org.trial_state. Rule-based risk checks (a signal matching an organization whose trial started less than 90 days ago; a free email provider plus any signal match; two or more signups from the same IP within 24 hours) do NOT reject the signup silently: the organization is still created and the user logged in (201), but with a pending_review subscription instead of a trial (org.trial_state=sms_required) — event ingestion stays blocked until the account is activated via SMS phone confirmation or by the manual review queue (email promise: within one business day).