feat(teams): the roster's audience projection, and optionalAuth to resolve it

TEAMS.md §3.3, as the eighth member of MODULE_API 1.6.0 — amended in place per
the org lead, on the rule Protocol 4 was given in phase 2: a contract owes a
bump only once it has landed on `main`.

Two questions meet on the roster and they belong to different owners. WHICH
ROWS a viewer may see is the module's, because the audience rungs and their
configuration live there and core does not know what a rung is. WHAT A ROW
LOOKS LIKE stays core's.

So `projectRoster` answers with member KEYS, not rows. §3.3 said rows, and rows
would let a module widen what is published — handing back a `userId` core had
withheld — leaving core's field guarantee resting on every module's good
behaviour. Core asks which rows and re-normalises the answer through its own
public shape, so a module can narrow and cannot widen.

"The module declines" needed splitting before it could be implemented. No
module at all and a module whose rungs could not be consulted are opposite
situations: the first withholds nothing and must serve the roster whole, the
second must serve none of it. The refusal carries `projects`, and only
`projects: true` fails closed. Without the split, bare core serves an empty
roster on every Team page.

This is also the first public route whose CONTENT depends on identity, which
needed a middleware core did not have. `attachSession` only decodes a token, so
a banned account, a password change or a logout would have kept working against
the private half of a feed until the JWT expired. `optionalAuth` runs
requireAuth's full database re-validation and, on any failure, continues
ANONYMOUSLY rather than rejecting — a caller whose session is no longer good
sees the public view, which is what they are entitled to.

`GET /public/teams/:slug/activity` lands here for the same reason: §2.11's route
table had no activity endpoint though §4.3 describes a filtered feed. Paged,
with the visibility resolved from the session and never from a parameter.

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

server/src/model/teams/teams.model.js

@@ -156,6 +156,16 @@ async function listPublic({ limit = 50, offset = 0 } = {}) {
     teams: visible.slice(offset, offset + limit).map(publicTeam),
     total: visible.length,
     ...sync,
+    // What the `teams` nav feature flag resolves from (§3.5). True if a provider
+    // is registered OR any Team exists — the second half matters because Team
+    // rows outlive the module that filled them, and hiding the nav entry the
+    // moment a module is uninstalled would make every existing Team page
+    // unreachable from the site while still answering by URL.
+    //
+    // False only when there is nothing and no prospect of anything, which is
+    // exactly the bare-core case the flag exists for: a link to a permanently
+    // empty page is worse than no link.
+    enabled: Boolean(sync.configured) || visible.length > 0,
   }
 }
 
@@ -174,6 +184,19 @@ async function getPublic(slug) {
   const successor = row.succeeded_by ? await teamsDb.findById(row.succeeded_by) : null
   return {
     ...publicTeam(row),
+    // The three props the `team.overview` extension slot is declared with
+    // (§3.4). A module's slot component runs in the browser and has to know
+    // WHICH Team it is looking at, in its own vocabulary — `slug` is core's name
+    // for it and resolves nothing on the module's side.
+    //
+    // On this route only, deliberately: the index has no slot and would
+    // otherwise publish a module-internal identifier per row for nothing. None
+    // of the three names a person — they are a core row id, a game-side group
+    // id and a module name, and the identifiers §3.2 withholds (member keys,
+    // site account ids) are not among them.
+    id: row.id,
+    externalId: row.external_id,
+    moduleId: row.module_id,
     ...sync,
     successor: successor && !successor.hidden
       ? { slug: successor.slug, name: successor.display_name_override || successor.name }
@@ -181,14 +204,50 @@ async function getPublic(slug) {
   }
 }
 
-async function rosterPublic(slug) {
+/**
+ * A Team's roster, projected for the caller's audience rung (§3.3).
+ *
+ * The ROW filter is the module's: it owns the visibility framework and its
+ * configuration (§10.5), and core does not know what a rung is. The FIELD shape
+ * stays core's — every row that survives goes through `publicMember`, which
+ * withholds the member key and the user id whatever the module answers. So a
+ * module can narrow what is published and cannot widen it, and core's "neither is
+ * published" guarantee does not rest on every module's good behaviour.
+ *
+ * **A module that HAS a rung system and cannot answer withholds the roster.** That
+ * is the one Team call where a refusal is not staleness: leaving a visibility
+ * answer "alone" would publish the very rows the rungs exist to withhold. A
+ * deployment with no module, or one whose module does not project at all, is a
+ * different case entirely — nothing is being withheld there, so the roster is
+ * served whole at core's public shape (`projects: false`).
+ */
+async function rosterPublic(slug, viewer = null) {
   const row = await teamsDb.findBySlug(slug)
   if (!row || row.hidden) return null
   const [members, sync] = await Promise.all([
     access.rosterWithOverrides(row.id),
     syncStatus(),
   ])
-  return { members: members.map(publicMember), ...sync, rosterSyncedAt: row.roster_synced_at }
+
+  // The module gets the rows as it supplied them — this is its own data coming
+  // home — plus who is asking, which is all a rung decision needs.
+  const answer = await teamProvider.projectRoster(row.external_id, members, viewer)
+  let visible
+  if (answer.ok) visible = members.filter((m) => answer.members.includes(m.member_key))
+  else if (answer.projects) visible = [] // fail closed: it has rungs and we could not ask
+  else visible = members                 // nothing to fail closed ABOUT
+
+  return {
+    members: visible.map(publicMember),
+    ...sync,
+    rosterSyncedAt: row.roster_synced_at,
+    // Stated rather than implied. An empty roster has three quite different
+    // causes — a Team with no members, a rung that shows none, and a module that
+    // could not be asked — and a page that cannot tell them apart will report the
+    // last one as the first.
+    projected: answer.ok,
+    ...(answer.ok || !answer.projects ? {} : { projectionUnavailable: true }),
+  }
 }
 
 // ── Player ─────────────────────────────────────────────────────────────────