Merge feat/multi-project (§22 M1+M2) into main

Integrates the multi-project work so far — the §22 design drafts, M1 (the
schema spine), and M2 (project-scoped authorization + the §22.7 resolver) —
on top of the v0.32.0 retire/§13 changes that landed on main meanwhile.

Integration decisions:
- Renumbered the M1 projects migration 025_projects.sql -> 026_projects.sql.
  v0.32.0 shipped 025_retired_state.sql, which rebuilds cached_rfcs and
  predates the project_id column; running projects *after* the retire rebuild
  is required so project_id survives on a fresh database (the runner applies
  *.sql in filename order). Comment/doc references bumped to match.
- Resolved the get_rfc conflict in api.py by composing both gates: compute the
  viewer once, apply the §22.5 visibility gate, then v0.32.0's §13.7
  retired-entry owner-only check.
- api_graduation.py / api_discussion.py auto-merged cleanly (M2's threaded
  viewer/visibility gate coexists with the new retire endpoints + retired
  state).

Full suite 401 passed on a fresh DB.

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

backend/app/projects.py

@@ -0,0 +1,40 @@
+"""Project registry — the §22 multi-project layer.
+
+A deployment hosts one or more projects (§22.1). Through Slice M1 the only
+project is the migration-seeded `default` one (the N=1 case, §22.13); the git
+registry mirror that lets a deployment declare more projects lands in M3 and
+will grow this module. For now this holds just the §22.13 step-1 backfill:
+completing the default project's row from deployment config, which pure-SQL
+migration 026 could not read.
+"""
+from __future__ import annotations
+
+from . import db
+from .config import Config
+
+DEFAULT_PROJECT_ID = "default"
+
+
+def seed_default_project(config: Config) -> None:
+    """Fill the default project's content_repo from config.
+
+    Migration 026 seeds `default` with content_repo NULL because SQL cannot
+    read the environment. This sets it from META_REPO (the pre-multi-project
+    single-corpus repo) the first time the configured app boots, so the row
+    accurately names the corpus the existing rows belong to. Idempotent: only
+    touches the row while content_repo is still unset, so a later registry
+    mirror (M3) that has populated it is never clobbered.
+
+    The display `name` is deliberately left as-is: the deployment's
+    user-visible name lives in the frontend build (VITE_APP_NAME) today and
+    moves to the registry + GET /api/deployment in M3 (§22.9); the backend has
+    no authoritative name to backfill from yet.
+    """
+    db.conn().execute(
+        """
+        UPDATE projects
+           SET content_repo = ?, updated_at = datetime('now')
+         WHERE id = ? AND content_repo IS NULL
+        """,
+        (config.meta_repo, DEFAULT_PROJECT_ID),
+    )