docs: consolidate repository guides and preserve audit history

docs/auth/2fa.md

@@ -1,8 +0,0 @@
-# 2fa
-
-Local accounts can enable TOTP from Profile settings. Setup requires the current password, verification
-of the first six-digit code, and acknowledgement of one-time recovery codes. Users can disable TOTP,
-regenerate recovery codes, list/revoke trusted devices, and revoke every trusted device.
-
-Challenge attempts are rate-limited. Recovery codes are hashed at rest and shown only when generated.
-See `docs/security/two-factor-authentication.md` for the detailed trust model.

docs/auth/login.md

@@ -1,9 +0,0 @@
-# login
-
-`POST /api/auth/login` accepts email, password, and remember-me preference. Successful local login
-issues an HttpOnly session cookie plus a readable CSRF cookie. Accounts with two-factor authentication
-receive a short-lived pending token and must complete `POST /api/auth/2fa/challenge` before a session is
-issued. Login and challenge endpoints are rate-limited.
-
-The frontend route is `/login`; registration has its own `/register` route. Authentication errors are
-shown without exposing whether an unknown account exists.

docs/auth/oauth.md

@@ -1,37 +0,0 @@
-# oauth
-
-Google and Microsoft sign-in exchange provider identity tokens for a normal Jobjakt local session.
-Microsoft sign-in validates the configured `Auth:MicrosoftTenant` mode, exact issuer/`tid`, audience,
-signature, lifetime, and GUID-shaped (`tid`, `oid`) pair. Microsoft email and
-`preferred_username` claims are display/contact metadata, not proof of mailbox ownership. Raw
-Microsoft bearer tokens are not accepted by application APIs; the exchange endpoint is the only
-Microsoft sign-in trust path.
-
-`Auth:MicrosoftTenant` accepts one tenant GUID, `organizations`, `consumers`, or explicit `common`.
-It is separate from `Microsoft:TenantId`, which controls Graph mailbox consent. Production requires
-the sign-in setting whenever `Auth:MicrosoftClientId` is enabled. The frontend receives the same
-value as `NEXT_PUBLIC_MICROSOFT_TENANT`, so its MSAL authority and the backend acceptance policy do
-not drift.
-
-`AspNetUsers.MicrosoftTenantId` plus `MicrosoftObjectId` is the unique Microsoft owner. Email is
-metadata and never auto-links or merges an existing Jobbjakt account. An authenticated password
-user must re-enter the current password to link or unlink; either change revokes every session and
-trusted device. Unlink is refused for passwordless accounts to avoid removing their last proven
-credential without a provider-reauthentication flow.
-
-Legacy `MicrosoftSubject`/`MicrosoftEmail` values are retained as evidence and are never backfilled.
-When exactly one legacy candidate is found, recovery sends a purpose-bound proof to its already
-confirmed application email. Confirmation also requires a fresh Microsoft token for the exact same
-(`tid`, `oid`) pair. Ambiguous/unconfirmed candidates require administrator-assisted verification;
-the application never guesses a tenant or silently merges accounts.
-
-Before enabling this release in production, apply `20260802212509_AddCanonicalMicrosoftIdentity`,
-run the counts-only legacy inventory in the deployment runbook, and keep Microsoft sign-in disabled
-if ambiguous rows cannot be handled. Rollback may keep the additive columns, but must never restore
-email auto-linking.
-
-Gmail and Microsoft Graph mailbox connections use separate OAuth flows and state validation because
-they grant mailbox permissions, not application login.
-
-Provider client IDs and secrets belong in environment configuration, never the repository. See
-`docs/architecture/authentication.md` and the connected-account settings UI.

docs/auth/overview.md

@@ -1,10 +0,0 @@
-# overview
-
-Jobjakt supports local email/password sessions plus optional Google and Microsoft identity exchange.
-Local access tokens are stored in an HttpOnly `jobtracker_session` cookie; mutating cookie-authenticated
-requests also require the double-submit CSRF token. Identity, sessions, two-factor authentication,
-trusted devices, email verification, and password reset are implemented by the controllers and services
-under `JobTrackerApi/Controllers` and `JobTrackerApi/Services`.
-
-Production authentication fails closed when required configuration is missing. See
-`docs/architecture/authentication.md` and `docs/security/authentication.md` for the security model.

docs/auth/signup.md

@@ -1,8 +0,0 @@
-# signup
-
-Self-service signup uses `POST /api/auth/register` and the `/register` frontend route. It is disabled
-unless `Auth:AllowRegistration`/`AUTH_ALLOW_REGISTRATION` is enabled. When Cloudflare Turnstile keys
-are configured, the server validates the widget token through Siteverify before creating the account.
-
-Production activation is intentionally blocked until the operator supplies Turnstile configuration;
-see `BLOCKERS.md`. Email verification can also be required before the first login.