[ci] Define release-critical verification once and reuse it across PR and publish workflows

[kang-heewon]

Priority

P1

Problem

Release-critical verification is currently defined in several partially overlapping places. CI, the Release workflow, root package scripts, release-spine-evidence, and the release-gate maintenance self-check each own their own command inventory.

This makes it possible for a PR to be green while a different post-merge verification path fails, and it causes the same expensive checks to run more than once without guaranteeing that the definitions stay equivalent.

Evidence

• Root package.json defines a broad pnpm check chain containing manifest, docs, provider, architecture, security, contract, public API, lint, and format checks.
• .github/workflows/ci.yml separately invokes several commands already included in pnpm check, including provider certification and security metadata checks.
• .github/workflows/release.yml runs pnpm check, a separate release-gate maintenance command list, and pnpm release:spine-evidence.
• scripts/release-spine-evidence.mts owns another explicit inventory of build, typecheck, test, generated-app, package smoke, production-ready, provider, coverage, and public API commands.
• [release] Run release-gate maintenance tests before merge #1306 demonstrates a concrete PR-green / post-merge-release-red failure caused by a verification inventory existing only in the Release workflow.
• [release] Run release-gate maintenance tests before merge #1306 correctly targets the release-gate maintenance test list; the broader release-critical command inventory remains duplicated after that issue is fixed.

Desired outcome

Repository, spine, and publish verification are defined from one authoritative command manifest. PR CI and Release select profiles from that same definition instead of maintaining parallel command lists.

Proposed implementation

1. Extract or export one authoritative verification manifest from the existing release verification code.
2. Define a small set of profiles using the same command IDs and implementations:
   • repo: fast read-only repository invariants;
   • spine: build/typecheck/test, public contracts, package/generated consumer smoke, and spine maturity gates;
   • publish: spine plus dependency policy, provenance configuration, and publish dry-run.
3. Keep command execution/reporting in the existing scripts; do not introduce a new CI framework.
4. Make workflows invoke root profile commands instead of embedding command inventories.
5. Reuse one change classifier to decide when a PR needs the spine profile.
6. Prevent the same command ID from running twice in one profile/job unless explicitly marked as defense-in-depth.
7. Add workflow contract tests that fail if a release-critical command is invoked outside the authoritative profile definition.

Acceptance criteria

• Every release-critical command ID is defined in exactly one source file/module.
• PR and Release workflows invoke shared profile commands rather than duplicating command lists.
• A deliberately broken spine/release command fails before merge whenever its relevant inputs change.
• The Release workflow still reruns publish-critical verification as defense in depth.
• pnpm check no longer hides duplicate heavyweight gates that are also invoked separately in the same job.
• Workflow tests detect a newly duplicated or Release-only verification command.
• Ordinary docs or isolated non-spine changes do not trigger the full publish profile.

Validation

• Add fixtures for repo-only, spine, release-gate-maintenance, and publish-candidate changes.
• Verify the selected profile and command IDs for each fixture.
• Break one shared command and prove both the appropriate PR path and Release path fail.
• Run scripts/tests/ci-workflow.spec.ts, scripts/tests/release-workflow.spec.ts, and scripts/tests/release-spine-evidence.spec.ts.

Related issues

• [release] Run release-gate maintenance tests before merge #1306
• [release] Let Version Packages PRs satisfy required checks automatically #1307

Scope boundaries

Do not build a generic workflow DSL or evidence bundle. Keep GitHub Actions responsible for scheduling and credentials; centralize only the existing release-critical verification definitions.