feat(teams): the phase 5 surface — discussion, replies, reports, and two admin screens

241 client tests pass (224 before).

**The forum panel becomes a forum.** It was "Announcements" with one composer;
it now has two, because phase 5 split one server capability into two: `canPost`
means "may open a discussion" and every participant may — a granted guest with no
game character included, which is path 3 doing its job — while `canAnnounce` is
the leader-only half `canPost` used to carry alone. Threads gain replies, an edit
control, per-post moderation and a report control, all still inside the one slot
the module declares, still navigating by `?thread=`.

**Almost nothing here is the client's decision, and the file says so.** `canPost`,
`canAnnounce`, `canReply` and each post's `canEdit`/`editableUntil` are read, not
computed. The one local judgement is a ticking clock that WITHDRAWS an edit offer
whose deadline passed while the page sat open — it can never grant one, because a
time-bounded permission must not take its clock from the party it bounds. That
asymmetry is the first thing client/test/teamForum.test.js asserts.

The panel's pure parts moved to `lib/teamForum.js` so they can be tested without a
browser, following teamActivity.js and teamAdmin.js. Two of them are subtler than
they look:

  * `stripToText` decodes entities AFTER stripping tags, and `&` last of all.
    Decoding first turns an author's literal "<script>" into a real tag the
    strip pass then deletes — silently losing text that was never dangerous.
  * `threadSummary` counts REPLIES, which is one fewer than `postCount`. Showing
    the raw count tells a reader a brand-new thread already has one reply.

**Three admin surfaces.** The forum settings screen gains the edit-window field
(0 = posts permanent once written). The reports queue is a new screen beside
Appeals — under moderation rather than under Teams, because a staffer working a
queue should have one place to work and `target_type` is deliberately open-ended,
so the next reportable thing arrives as a row rather than as another nav entry.
Its copy tells a member where a report lands and that reporting changes nothing,
because a member who expects a post to vanish and watches it stay reports it
again. There is no leader-facing view and there is not meant to be.

And the per-Team forum moderation ledger finally renders: the route and
`api.admin.teamForumModeration()` have both existed since phase 4 with nothing
calling them, which made `actor_role` — the column that keeps a leader's ordinary
housekeeping distinguishable from a staff intervention — readable only from a DB
client.

Co-Authored-By: Claude <noreply@anthropic.com>

client/src/routes/admin/views/TeamsAdmin.jsx

@@ -152,7 +152,7 @@ function RequestQueue({ rows, role, onDecide, busy }) {
 
 // ── One Team ───────────────────────────────────────────────────────────────
 
-function TeamRow({ team, role, onAct, busy }) {
+function TeamRow({ team, role, onAct, busy, onLedger }) {
   const status = statusOf(team)
   return (
     <tr>
@@ -181,11 +181,84 @@ function TeamRow({ team, role, onAct, busy }) {
               Hide
             </button>
           ))}
+        <button type="button" className="btn" onClick={() => onLedger(team)} style={{ marginLeft: 6 }}>
+          Forum log
+        </button>
       </td>
     </tr>
   )
 }
 
+/**
+ * One Team's forum moderation ledger (TEAMS.md §5.3).
+ *
+ * The route and the API method have existed since phase 4 and nothing rendered
+ * them, which made the ledger a table only a DB client could read. The column
+ * that earns the screen is `actorRole`: it records WHICH authority was exercised,
+ * so a leader's ordinary housekeeping stays distinguishable from a staff
+ * intervention after the fact.
+ *
+ * **This is deliberately not merged with the site's mod_actions/appeals pair.**
+ * That one is Discord-sanction-shaped and bot-owned; routing a guild leader
+ * locking a thread through it would make ordinary housekeeping an appealable
+ * sanction with a reversal path into the bot. Every STAFF-exercised action here
+ * additionally writes activity_log, so the site's accountability trail sees it —
+ * the two are cross-referenced, not merged.
+ */
+function ForumLedger({ team, onClose }) {
+  const [rows, setRows] = useState(null)
+  const [error, setError] = useState('')
+
+  useEffect(() => {
+    let active = true
+    api.admin.teamForumModeration(team.id)
+      // `{ entries }`, and the rows are the ledger table's own snake_case
+      // columns — this endpoint serves them unmapped, unlike the Team payloads
+      // above it. Reading them as they are, rather than accepting three possible
+      // shapes, is what makes a change to that endpoint fail here instead of
+      // rendering an empty table.
+      .then((res) => { if (active) setRows(res.entries) })
+      .catch((err) => { if (active) setError(err.message || 'Could not load the forum log.') })
+    return () => { active = false }
+  }, [team.id])
+
+  return (
+    <section className="panel">
+      <header style={{ display: 'flex', justifyContent: 'space-between', alignItems: 'baseline' }}>
+        <h2>Forum log — {team.displayName}</h2>
+        <button type="button" className="btn" onClick={onClose}>Close</button>
+      </header>
+      {error && <ErrorState message={error} />}
+      {!rows && !error && <Loading />}
+      {rows && rows.length === 0 && <p className="muted">Nothing has been moderated in this forum.</p>}
+      {rows && rows.length > 0 && (
+        <table className="table">
+          <thead>
+            <tr>
+              <th>When</th><th>Action</th><th>Target</th><th>By</th><th>As</th><th>Reason</th>
+            </tr>
+          </thead>
+          <tbody>
+            {rows.map((r) => (
+              <tr key={r.id}>
+                <td className="muted">{dateTime(r.created_at)}</td>
+                <td>{r.action}</td>
+                <td className="muted">{r.target_type} #{r.target_id}</td>
+                <td>{r.actor_username || '—'}</td>
+                <td>
+                  {/* The distinction the whole ledger exists to preserve. */}
+                  <Pill tone={r.actor_role === 'staff' ? 'warn' : 'ok'}>{r.actor_role}</Pill>
+                </td>
+                <td className="muted">{r.reason || '—'}</td>
+              </tr>
+            ))}
+          </tbody>
+        </table>
+      )}
+    </section>
+  )
+}
+
 // ── The screen ─────────────────────────────────────────────────────────────
 
 export default function TeamsAdmin() {
@@ -198,6 +271,7 @@ export default function TeamsAdmin() {
   const [error, setError] = useState('')
   const [notice, setNotice] = useState('')
   const [busy, setBusy] = useState(false)
+  const [ledgerTeam, setLedgerTeam] = useState(null)
 
   const load = useCallback(async () => {
     setError('')
@@ -265,6 +339,8 @@ export default function TeamsAdmin() {
       {error && <ErrorState message={error} />}
       {notice && <p className="notice">{notice}</p>}
 
+      {ledgerTeam && <ForumLedger team={ledgerTeam} onClose={() => setLedgerTeam(null)} />}
+
       <SyncPanel sync={data} syncState={data.syncState} onResync={resync} busy={busy} />
       <ReviewQueue rows={review} role={role} onAct={act} busy={busy} />
       <RequestQueue rows={requests} role={role} onDecide={decide} busy={busy} />
@@ -288,7 +364,14 @@ export default function TeamsAdmin() {
             </thead>
             <tbody>
               {data.teams.map((team) => (
-                <TeamRow key={team.id} team={team} role={role} onAct={act} busy={busy} />
+                <TeamRow
+                  key={team.id}
+                  team={team}
+                  role={role}
+                  onAct={act}
+                  busy={busy}
+                  onLedger={setLedgerTeam}
+                />
               ))}
             </tbody>
           </table>