docs: ADR-019 (Authentik owns invites), supersede ADR-017

Record the invite-provisioning removal; mark ADR-017 superseded; fix
ui-spec invite-onboarding + auth-delegation sections to reflect Authentik.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

DECISIONS.md

@@ -524,7 +524,11 @@ about editing a gate while it's unmet) so the reasoning survives, not just the n
 
 ## ADR-017 — Invite flow: Tapir creates Dex local-password accounts (write access to the shared identity provider)
 
-**Status:** Accepted (2026-06-03), **recorded retroactively during reconciliation, then
+**Status:** ~~Accepted~~ **SUPERSEDED by [ADR-019](#adr-019--authentik-owns-invites-tapir-stops-provisioning-accounts) (2026-06-07).** The Dex local-password
+invite provisioning was removed when the homelab IdP migrated Dex→Authentik
+(infra ADR-0001); Authentik now owns invites. Original record below.
+
+Accepted (2026-06-03), **recorded retroactively during reconciliation, then
 deliberately ratified KEEP (2026-06-03).** This capability **shipped in v0.7.0 without an ADR** —
 code, RBAC, and a deployed ServiceAccount landed before any decision record existed. This ADR
 documents what shipped and honestly records that the decision-before-code discipline was not
@@ -662,6 +666,37 @@ Spec: `docs/specs/scheduled-discovery.md`.
 
 ---
 
+## ADR-019 — Authentik owns invites; Tapir stops provisioning accounts
+
+**Status:** Accepted (2026-06-07). **Supersedes ADR-017** (Dex local-password invite
+provisioning).
+
+**Context:** infra ADR-0001 migrated the homelab IdP Dex→Authentik. Authentik provides
+first-class invite flows; the Dex local-password connector never consulted the Password
+CRs Tapir wrote (the defect that triggered the migration). Tapir-web's OIDC issuer now
+points at Authentik (infra ADR-0001 step 3).
+
+**Decision:** Tapir no longer provisions accounts. The Dex-password invite path is removed:
+`internal/adapters/dex`, the public `/invite/{token}` set-password UI (`internal/web/invite.go`),
+the `tapir invite` CLI (`cmd/tapir/invite.go`), the `InvitationStore`/`DexPasswordCreator`
+ports + `App.Invitations`/`App.Dex` wiring, the invite Templ pages, and the
+`tapir invite` Taskfile target. New users are invited via Authentik's flow, log into Tapir
+via OIDC, and are captured by Tapir's existing provider-agnostic `/register` (display name).
+Login + Google moved by config only (Authentik per-app issuer); the OIDC adapter is unchanged.
+
+**Consequences:** smaller Tapir blast surface — no writes to the shared identity provider, no
+configmap/CR access, the dedicated `passwords.dex.coreos.com` RBAC + ServiceAccount are
+removed (infra side, coupled change). The `invitations` table (migration 009) is left in
+place — migrations are append-only and the unused table is harmless; a future migration may
+drop it. The `*_DEX_*` config/identity names (`TAPIR_DEX_CLIENT_*`, `dex_subject`, the
+`DexAuth`/`oidc` package) are now misnomers; renaming is deferred (cosmetic, not behavioural).
+
+**Rejected:** keeping Tapir's `/invite` UI but calling Authentik's API on claim — couples
+Tapir to Authentik's admin API + a token for no real gain; Authentik's own invite flow is
+the supported path.
+
+---
+
 ## Rejected alternatives
 
 Approaches considered during the 2026-06-02 planning + grill session and **deliberately not