feat(safety): report, block and hide, MODULE_API 1.21.0

USER_SAFETY.md step 2 (core), with S11-S14 decided while building it.

- Reports: POST /player/reports takes any target type, core's forum
  types or a module's registered ones. One resolver
  (model/safety/targets.js) answers "what is this item, for this
  reader" and 404s an item the reader cannot see. Every report stores
  content_reports.snapshot; the queue shows a module item from it.
- Hide for everyone: POST /admin/moderation/reports/:id/hide hides the
  item through its own moderation (forum hide as staff, or the module's
  hide) and actions the report with actioned_with = 'hide'.
- Blocks (user_blocks) name an item, never a person, and land on the
  author's account first (S12); an unlinked game identity is blocked as
  itself and becomes an account block once linked (S14). Staff cannot
  be blocked; a block on someone later promoted stops applying (S8).
- Hide for me (user_hidden_items), /auth/me/blocks and /auth/me/hidden.
- Forum reads filter blocked authors and hidden items on the server and
  carry canBlock per thread and post.
- MODULE_API 1.21.0: api.registerReportTargets,
  api.registerGameIdentities, ctx.safety.forViewer and
  ctx.safety.staffAmong, so a module filters its own per-viewer feeds on
  the server (S11) and marks lines canBlock (S13).
- Web: Hide for me / Block author in the forum menus, a Blocked section
  on both account pages, Hide for everyone in the Reports queue.
- Tests, OpenAPI, route/guard/engagement manifests regenerated.

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

server/db/schema.sql

@@ -1301,6 +1301,72 @@ CREATE TABLE IF NOT EXISTS content_reports (
   INDEX idx_cr_team (team_id, created_at)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
+-- What the reported item said when it was reported (USER_SAFETY.md §4.1). A chat
+-- line is pruned with the rest of a module's event log, and a queue row must still
+-- show what was said after that; a forum author editing a post after the report
+-- must not change what staff read. NULL on reports filed before 1.21.0.
+--
+-- `actioned_with` names what the queue DID when a staffer actioned a report
+-- through it ('hide' — hide for everyone). NULL for an "actioned" that only
+-- records a decision, which is every report before 1.21.0.
+ALTER TABLE content_reports ADD COLUMN IF NOT EXISTS snapshot JSON NULL;
+ALTER TABLE content_reports ADD COLUMN IF NOT EXISTS actioned_with VARCHAR(16) NULL;
+
+-- A member's blocks (USER_SAFETY.md §4.1, S2, S12, S14). Saved on the account,
+-- so a block applies on the website and in the app, on every device.
+--
+-- Two kinds of row, never both at once:
+--   • an ACCOUNT block names `blocked_user_id`. This is the normal block (S12):
+--     a forum author, and a chat speaker whose game identity is linked to an
+--     account, are blocked as the account.
+--   • a GAME block names (`module_id`, `identity_kind`, `external_id`) — a
+--     Steam id in a chat feed that no account has linked. When that identity is
+--     later linked, the row is rewritten as an account block the next time it is
+--     read (S14).
+--
+-- Staff cannot be blocked (S8). The refusal happens when the block is made; a
+-- row whose target LATER became staff is kept and simply stops applying, so the
+-- Blocked page can say why rather than the block vanishing.
+--
+-- Each kind has its own unique key, and MySQL's NULL-distinct rule keeps them
+-- out of each other's way: an account row's game columns are NULL, and a game
+-- row's `blocked_user_id` is.
+--
+-- `display_name` is a snapshot of what the member saw when they blocked: the
+-- username, or the in-game name of an unlinked speaker.
+CREATE TABLE IF NOT EXISTS user_blocks (
+  id              INT AUTO_INCREMENT PRIMARY KEY,
+  blocker_user_id INT          NOT NULL,
+  blocked_user_id INT          NULL,
+  module_id       VARCHAR(32)  NULL,
+  identity_kind   VARCHAR(32)  NULL,
+  external_id     VARCHAR(64)  NULL,
+  display_name    VARCHAR(64)  NULL,
+  created_at      DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP,
+  CONSTRAINT fk_ub_blocker FOREIGN KEY (blocker_user_id) REFERENCES users(id) ON DELETE CASCADE,
+  CONSTRAINT fk_ub_blocked FOREIGN KEY (blocked_user_id) REFERENCES users(id) ON DELETE CASCADE,
+  UNIQUE KEY uq_ub_account (blocker_user_id, blocked_user_id),
+  UNIQUE KEY uq_ub_game (blocker_user_id, module_id, identity_kind, external_id),
+  INDEX idx_ub_external (module_id, identity_kind, external_id)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
+
+-- A member's "Hide for me" (USER_SAFETY.md §1, S3): one item gone from their own
+-- view on every device. No report is filed and nothing about the item changes.
+--
+-- `target_type` is a report target type (`team_forum_thread`, `team_forum_post`,
+-- or a module's, e.g. `rust.chat`) and `target_id` its id. Nothing checks the
+-- item exists: answering "no such item" would tell a member whether a thread id
+-- exists in a forum they cannot see, and a row for an item that is not there
+-- hides nothing.
+CREATE TABLE IF NOT EXISTS user_hidden_items (
+  user_id      INT          NOT NULL,
+  target_type  VARCHAR(32)  NOT NULL,
+  target_id    BIGINT       NOT NULL,
+  created_at   DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP,
+  PRIMARY KEY (user_id, target_type, target_id),
+  CONSTRAINT fk_uhi_user FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
+
 -- The §2.9 approval queue. A MODERATOR performing one of the three actions that
 -- publish untrusted game-sourced strings creates a pending row here; an ADMIN
 -- performing one applies it immediately. Rows are kept after a decision — "a