feat(moderation): appeals (6c) + Discord reversal on approve (6d)

Players whose linked Discord identity was banned or muted can now submit
an appeal from the portal and track it; staff get a queue in the admin
moderation section to claim and resolve (approve/deny) appeals. Approving
a ban/mute appeal best-effort asks the Discord bot to reverse the action
(unban / clear timeout) via the internal API and posts a mod-log embed; a
down bot never fails the resolution (reversal_status is recorded).

- Schema: new server-owned `appeals` table (no cross-owner FK to
  mod_actions; existence validated in app code).
- Server: model/appeals/* + player appeals controller (submit/mine/
  eligible/withdraw) and admin queue handlers (list/claim/resolve/
  per-user) under the existing admin+moderator gate; one-active-appeal
  enforced app-side; eligibility keyed on the caller's linked Discord id.
- 6d: bot POST /internal/mod-reverse (+ modLog.postReversal) and
  server botInternalClient.reverseModAction, wired into resolve().
- Client: admin Appeals queue + resolve modal, ModerationUser appeals
  tab, player Appeals page (submit/withdraw), nav + routes + api methods.
- Docs: swagger annotations + component schemas, regenerated output.
- Tests: appeals controller + pure suites (server npm test 224 green).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XmHdsbnLzDMAVQkAoTQSBe

server/src/model/appeals/appeals.pure.js

@@ -0,0 +1,48 @@
+// Pure helpers for the moderation-appeals feature (Phase 6c). No DB access —
+// just the status/type vocabularies and row-shaping so both the model layer and
+// the tests can reason about appeal state without a database.
+
+// Terminal statuses: an appeal that has reached one of these is closed and can
+// no longer be withdrawn, claimed, or resolved.
+const TERMINAL = new Set(['approved', 'denied', 'withdrawn'])
+
+// Active statuses: an appeal that still occupies the "one active appeal per
+// action" slot. A player cannot open a second appeal for a mod_action while one
+// of these is outstanding.
+const ACTIVE = new Set(['pending', 'under_review'])
+
+// Only bans and mutes are appealable (kicks/warns are not — a kick is not a
+// standing state, and a warn carries no access restriction to reverse).
+const APPEALABLE_TYPES = new Set(['ban', 'mute'])
+
+// True if a status is one an appeal can still transition away from.
+function isTerminal(status) {
+  return TERMINAL.has(status)
+}
+
+function isActive(status) {
+  return ACTIVE.has(status)
+}
+
+function isAppealableType(actionType) {
+  return APPEALABLE_TYPES.has(actionType)
+}
+
+// Map an approve/deny resolution to the reversal_status the row should carry.
+// A denial never reverses; an approval only reverses when the underlying action
+// is appealable (ban/mute) and the bot call succeeded.
+function reversalStatusFor({ status, actionType, botOk }) {
+  if (status !== 'approved') return 'none'
+  if (!APPEALABLE_TYPES.has(actionType)) return 'none'
+  return botOk ? 'done' : 'failed'
+}
+
+module.exports = {
+  TERMINAL,
+  ACTIVE,
+  APPEALABLE_TYPES,
+  isTerminal,
+  isActive,
+  isAppealableType,
+  reversalStatusFor,
+}