feat: add authoritative verification goal registry revisions

[Joncallim]

Part of #187

What changed

• Records every complete repository registry import as an immutable, predecessor-linked project revision, including an authoritative empty registry.
• Advances one protected current-head projection only after the project owner, active state, repository identity, grant revision, project revision, ordered membership, and manifest digest are rechecked atomically.
• Moves revision construction behind a fixed-search-path protected PostgreSQL routine. The ordinary app login can read revision history but cannot directly mutate revisions, memberships, or heads.
• Upgrades the import response to schema version 2 with the authoritative revision id, manifest digest, and whether the head advanced or already existed.
• Splits the protected migration path into exact 0028 and 0033 stages, each with independent failure-safe authority cleanup.
• Tightens managed-install privilege reconciliation and documents that the stored actor is asserted by the authenticated application session, not independently authenticated by PostgreSQL.

Why

Immutable snapshots alone cannot tell a future runner which complete registry is current. Removed, disabled, or superseded goals could otherwise be selected from history. This slice creates an explicit authoritative head without authorizing execution, queueing, outcomes, or reliability claims.

Validation

• Final primary focused suite: 8 files, 73 tests passed.
• TypeScript: passed.
• Independent QA: fresh PostgreSQL 16 migration through 0033, 10 registry tests, forced handoff failure and retry, installer proof, lint, and diff checks passed.
• Full orthogonal Review: no blockers found in the inspected scope.
• Security/Adversarial review: no blockers found in the inspected scope.
• Hosted Web CI remains required for the full installer, legacy-repair, and Linux proof matrix.

Scope boundary

This PR stores and selects authoritative definitions only. It does not run a goal, enqueue work, create evidence, change autonomy, create findings, or repair code. Issue #187 remains open for the later policy, run-ledger, authority, manual-run, history, and scheduling slices.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e87e7b4419

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Route all upgrades through the 0033 handoff

When a database at 0032 is upgraded through a custom/Docker installation, forge repair, or another documented migration command, those entrypoints still invoke plain npm run db:migrate (scripts/install.sh:1612-1615, scripts/repair.sh:644-648, and scripts/setup.sh:123). The previous protected-migration finalizer revokes the migration login's access to this bootstrap routine, so this unconditional call fails before any 0033 tables are created; only the managed-native installer path restores the grant via apply-verification-goal-registry-migration.sh. Route every supported migration entrypoint through the bounded administrator handoff, or integrate that handoff into the canonical migrator.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Permit the configured application login to commit revisions

In deployments where the ordinary application login is not literally forge, every registry import is rejected here even if the role is granted EXECUTE. This is a supported configuration: provision-epic-172-application-role.ts:63-76 derives an arbitrary direct application login from FORGE_APPLICATION_DATABASE_URL, and the operator guide uses forge-app as its example. Because the migration also grants this routine only to forge, such deployments cannot use the new import endpoint at all; provision, grant, and validate the actual configured application principal instead of hard-coding the local-install role name.

Useful? React with 👍 / 👎.