Registry-table refusal in a session store blocks project open; beta.63 profiles need two wipe --stale rounds

[ScriptedAlchemy]

Problem

Every registered store (global.db, user-sessions.db, each projects/<id>/sessions.db) carries the full registered schema, including the project-registry tables. A profile written by v1.0.0-beta.63 therefore has the retired graph_scopes.db_relpath column in its session stores too.

A session store whose registry tables have that shape is refused at attach with authority project registry as a hard error, not as a sessions-scoped refusal (#2648's rule). The project sessions store is also the project's configuration database, so project open fails on it:

$ tracedecay init <git project>          # after `wipe --stale` reset global.db (#2877)
Error: project route error (application.reset-required)
Reset authority: project registry
Reset reason: database error: table 'graph_scopes' has an incompatible number of columns (operation: validate global database authority schema)
Reset remedy: tracedecay wipe --stale --yes

Because the daemon only learns of a refused project sessions store when it opens that project, and project open stops at a refused profile authority first, a beta.63 profile needs two wipe --stale --yes rounds: the first resets global.db and user-sessions.db; each project's sessions.db is named only after its first init, and the second round resets it.

Reproduced on fleet/scoped-profile-reset (#2877) with an isolated profile: init a git project, age all three registered stores to the beta.63 graph_scopes shape, wipe --stale --yes, run the printed tracedecay init, observe the refusal above, wipe --stale --yes again, init succeeds and serves the unchanged code generation and project memory.

Expected

Either a registry-table refusal in a session store refuses only what reads those tables (the session store does not serve the registry), or the census names every refused registered store before the first reset, so one wipe --stale --yes resets them all.