§22 M3-backend Plan B (1/2): slug-keyed PK rebuilds activate project #2 (v0.36.0)

Lands the table rebuilds migration 026 deferred until a second project exists,
shipped separately from per-project serving for migration hygiene. No behavior
change (deployments stay single-project 'default').

- migration 028_project_scoped_keys.sql: folds project_id into the slug-keyed
  PK/UNIQUE of 13 tables (cached_rfcs PK (slug)->(project_id,slug); the
  UNIQUE/PK on cached_branches, branch_visibility, branch_contribute_grants,
  stars, watches, pr_seen, branch_chat_seen, funder_consents, rfc_collaborators,
  contribution_requests, proposed_use_cases gain project_id) and makes the FKs
  to cached_rfcs on rfc_invitations/rfc_collaborators/contribution_requests
  composite (project_id, rfc_slug) -> cached_rfcs(project_id, slug).
- db.run_migrations: a `-- migrate:no-foreign-keys` migration runs with
  PRAGMA foreign_keys toggled OFF around it (required by SQLite's table-rebuild
  procedure) + foreign_key_check after, failing loudly on dangling refs.
- ON CONFLICT upsert targets for the rebuilt tables gain project_id so they
  match the new composite indexes (value still defaults to 'default').
- test_migration_028_project_scoped_keys.py: proves two-project same-slug
  coexistence, within-project uniqueness, composite-FK enforcement. 442 pass.
- design doc §2 marked shipped.

Per docs/superpowers/specs/2026-06-04-m3-backend-planb-design.md.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

backend/app/db.py

@@ -48,7 +48,29 @@ def run_migrations(config: Config) -> None:
             if version in applied:
                 continue
             sql = path.read_text()
-            conn.executescript("BEGIN; " + sql + "; COMMIT;")
+            if "-- migrate:no-foreign-keys" in sql:
+                # SQLite table rebuilds (changing a PRIMARY KEY / UNIQUE, e.g.
+                # folding project_id into a composite key) follow the official
+                # 12-step ALTER procedure, which requires FK enforcement OFF —
+                # and `PRAGMA foreign_keys` is a no-op *inside* a transaction, so
+                # it must be toggled here, around the script. The connection is
+                # in autocommit mode (isolation_level=None), so the PRAGMA takes
+                # effect immediately. We re-enable and run foreign_key_check
+                # after, failing the migration loudly if the rebuild left any
+                # dangling reference.
+                conn.execute("PRAGMA foreign_keys = OFF")
+                try:
+                    conn.executescript("BEGIN; " + sql + "; COMMIT;")
+                    violations = conn.execute("PRAGMA foreign_key_check").fetchall()
+                    if violations:
+                        raise RuntimeError(
+                            f"migration {version} left foreign-key violations: "
+                            f"{[tuple(v) for v in violations]}"
+                        )
+                finally:
+                    conn.execute("PRAGMA foreign_keys = ON")
+            else:
+                conn.executescript("BEGIN; " + sql + "; COMMIT;")
             conn.execute("INSERT INTO schema_migrations (version) VALUES (?)", (version,))
     finally:
         conn.close()