feat(projects): M2 — project-scoped authorization + the §22.7 resolver (§22)

Builds the three-tier authorization resolver on M1's schema spine: the
most-permissive union of deployment role (§6.1), project role (§22.6), and
per-RFC authority (§6.3/§12), with the §22.5 visibility gate subtractive on
top (§22.7). Pure app-layer — no migration (M1 shipped the tables), no
behavior change on the public default project. Verifiable on the single
default project by flipping its visibility and granting/revoking roles.

- app/auth.py: the §22.7 resolver primitives — project_visibility,
  project_member_role, project_of_rfc, is_project_superuser, can_read_project,
  effective write/discuss standing (can_contribute_in_project /
  can_discuss_in_project), require_project_readable, visible_project_ids.
  The three per-RFC capability helpers (can_discuss_rfc / can_contribute_to_rfc
  / can_invite_to_rfc) now compose all three tiers, so the ~20 call sites
  inherit M2 unchanged.
- Read pass: the §22.5 visibility gate (404 to non-members) threaded into
  every RFC-resolution helper across api.py / api_branches / api_prs /
  api_graduation / api_discussion / api_contributions / api_invitations, plus
  the catalog + proposals listings filtered by visible_project_ids.
- Write pass: the deep gates (branch read/contribute/owner, PR merge/withdraw/
  edit, graduation, discussion resolve) fold in project_admin via
  is_project_superuser; the "any-contributor" branch mode routes through
  can_contribute_in_project; propose + claim gate on project contribute
  standing. Deployment-level surfaces (admin idea-PR merge/decline, account
  notification-mute) stay deployment-scoped.
- Operator decisions: implicit-on-public (a granted deployment contributor
  keeps its pre-M2 write baseline on a public project, no membership row, so
  the N=1 case stays whole) and preserve-curation (that baseline does not
  override per-RFC owner curation — only an explicit project grant or a
  deployment owner/admin does), keeping the v0.16.0 per-RFC invite contract
  intact on public.
- tests: test_multi_project_authz_vertical.py — 9 vertical assertions on the
  resolver tiers, public-unchanged regression, the gated 404 read gate, the
  gated contribution gate, union + subtractive visibility, and revocation.
  Full suite 390 passed.
- docs: mark Part C M2 "(landed)" with the two operator decisions.

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

docs/design/multi-project-spec.md

@@ -484,13 +484,32 @@ single project, with the spine underneath. Additive only: no table rebuilds
 project #2, enumerated in migration 025's header). This is the foundation
 everything after builds on.
 
-**M2 — Project-scoped authorization + the §22.7 resolver.** The three-tier
-composition: `project_members` roles, the most-permissive union with
-deployment role and per-RFC authority, the §22.5 visibility gate as a 404 on
-read and 401/403 on write. Every §17 write endpoint surveyed in §6.1's audit
-re-checked under the project axis. Still single visible project; this slice
-is verifiable by granting/revoking roles on the default project and asserting
-the gates.
+**M2 — Project-scoped authorization + the §22.7 resolver.** *(landed)*
+The three-tier composition: `project_members` roles, the most-permissive
+union with deployment role and per-RFC authority, the §22.5 visibility gate as
+a 404 on read and 401/403 on write. Every §17 write endpoint surveyed in
+§6.1's audit re-checked under the project axis. Still single visible project;
+verifiable by granting/revoking roles on the default project and flipping its
+visibility (`backend/tests/test_multi_project_authz_vertical.py`). Pure
+app-layer — the resolver primitives live in `app/auth.py`
+(`project_visibility`, `project_member_role`, `is_project_superuser`,
+`can_read_project`, `can_contribute_in_project`, `require_project_readable`,
+`visible_project_ids`), composed into the existing per-RFC capability helpers
+and threaded into every RFC-resolution gate (`_require_rfc*`,
+`_require_super_draft`, `_require_rfc_readable`, the branch/PR/graduation deep
+gates). No migration (M1 shipped the tables) and no behavior change on the
+public default project.
+
+Two operator decisions pin how the implicit grant behaves on a `public`
+project: **implicit-on-public** — a granted deployment `contributor` keeps its
+pre-multi-project write baseline with no `project_members` row, so the N=1 case
+stays whole (no backfill); and **preserve curation** — that implicit baseline
+does *not* override per-RFC owner curation (only an explicit
+project_contributor/admin or a deployment owner/admin does), so the v0.16.0
+per-RFC invite contract is unchanged on public. Explicit `project_members`
+rows and `gated`/`unlisted` visibility are where the new tier bites. This is a
+deliberate liberalization of §22.5's literal "contributing still requires a
+grant" for the public case; gated/unlisted honor the grant model exactly.
 
 **M3 — Registry mirror + routing + runtime branding.** The §4 registry
 mirror (webhook + reconciler over the `REGISTRY_REPO`, populating `projects`