docs(design): record owner decisions on game account management

Reframes the feature as an identity bridge: these emulators do not and
will not speak OIDC, each ships its own login against its own auth DB, so
the value is tying one SSO identity to one native account per server.

That makes two former open questions answers rather than choices - one
account per user per server IS the feature, and no authorization gate
beyond a Drop session, since Drop access and game access already imply
each other and a third check could only disagree with them.

Retail TrinityCore on hold.

docs/design/0002-game-account-management.md

@@ -8,6 +8,30 @@ admin, for every live server. Drop becomes the single account surface; the
 `mmo.quasarke.net` portal keeps its archive/catalog job and stops being an
 identity tool.
 
+## What this actually is: an identity bridge
+
+**None of these emulators support OIDC, and none of them are going to.** Every
+one ships its own login solution against its own auth database — EQEmu's
+loginserver tables, TrinityCore's SRP6 verifiers, OpenDAoC's own scheme. That
+is not a gap to be closed; it is the permanent shape of the problem.
+
+So this feature is not SSO for the game servers. It is a **bridge**: one Drop
+(SSO) identity, tied to one native game account per server, so a player has a
+single place to create, find and reset credentials they will then type into a
+game client that has never heard of Authentik.
+
+Two things follow directly, and they are the answers to what would otherwise
+be open design questions:
+
+- **One account per user per server.** Not a limitation imposed for tidiness —
+  it is what "tie my SSO identity to my account on that server" means. The
+  unique constraint on `(userId, serverSlug)` is the feature.
+- **No separate authorization gate.** If a user can reach Drop and reach the
+  game, they may create an account. Drop membership already implies the former
+  and the `game-access` group already implies the latter, so a third check
+  would only add a way for the two to disagree. Provisioning is gated on an
+  authenticated Drop session and nothing else.
+
 ## Why move it rather than link to it
 
 mmo-portal already solves this properly. It has a real cross-game abstraction
@@ -71,15 +95,18 @@ Five live servers, from the probe registry:
 |---|---|---|---|
 | EQEmu (EverQuest) | `eqemu` | `peq.account` + loginserver, MariaDB | ✅ `eqemu.py` |
 | TrinityCore WotLK | `wow` | SRP6 auth DB, MySQL | ✅ `trinitycore.py` |
-| TrinityCore retail | (tbd) | separate auth DB, same schema family | ✅ reuse `trinitycore.py`, second config |
 | OpenDAoC | `daoc` | own auth DB | ✅ `opendaoc.py` |
 | Impostor (Among Us) | — | **no accounts at all** | n/a — status only |
+| TrinityCore retail | — | **ON HOLD** (owner, 2026-08-07) | deferred |
 
-So: four of five need account management and all four already have a working
+So: three servers need account management and all three already have a working
 provider. Impostor is a lobby server with no identity; it gets status and join
 instructions only, and the UI must not render an account panel for it. That is
 exactly what `is_configured()` returning False already expresses.
 
+Retail TrinityCore is deferred, not designed out — when it lands it is a
+`GameServer` row plus a second `trinitycore.py` config, no new code.
+
 ## Design
 
 ### Port the layer, don't rewrite it
@@ -191,12 +218,17 @@ pipeline. See [[drop-launcher-button-patch]].
 Phase 1 is independently useful: it makes the provider layer callable from
 anything, including scripts.
 
-## Open questions for the owner
+## Decisions (owner, 2026-08-07)
 
-- **Retail TrinityCore slug** — it needs its own `GameServer` row and provider
-  config; is it in the registry yet?
-- **Who may create a game account?** Any Drop user, or gated on the
-  `game-access` / `mmo_user` groups? Drop membership is currently the implicit
-  answer; worth being explicit.
-- **One game account per user per server**, or several? The unique constraint
-  above assumes one.
+- **Retail TrinityCore is on hold.** Not in scope; costs nothing to add later.
+- **Authorization: none beyond a Drop session.** If a user can access Drop and
+  access the game, they can make an account. No `game-access` / `mmo_user`
+  check in this code path — see "identity bridge" above for why a third gate
+  would only create disagreement between two existing ones.
+- **One account per user per server.** Unique on `(userId, serverSlug)`.
+
+## Open
+
+- **Does `LinkedAuthMec.credentials` carry the Authentik `sub`?** Determines
+  whether the existing mmo-portal links migrate by join or by one-time
+  re-confirmation. Verify before building phase 2; do not assume.