ci: spec-driven release process — maintainer tags, binaries gate packages

[taras]

Motivation

Cutting a release was CLI-only, publish-packages.yml was dispatchable with a
typed version string (publishing npm versions with no corresponding binary),
the release process lived in scattered workflow comments, and the CLI
hardcoded its version separately from the manifests.

Approach

• specs/release-process-spec.md (new): the single reference for the
  release process — sequence diagram, version lockstep, OIDC trusted-publisher
  settings, setup, new-package bootstrap, recovery. Absorbs
  .github/PUBLISHING.md; workflows carry only operational comments pointing
  at the spec.
• Maintainers create tags; no workflow does. A release is cut from the
  GitHub Releases UI ("Create new tag on publish" targeting main) or by
  pushing a tag. No PAT, no tag workflow.
• The tag is the only publish trigger: publish-packages.yml drops
  workflow_dispatch (via its generator).
• Version guards move into the pipeline: release.yml fails fast when the
  tag does not match cli/deno.json; the generated version job validates
  the tag against every manifest.
• Packages publish only after binaries exist: the version job polls the
  release.yml run for the same commit and fails if the binary build fails,
  so npm versions never exist without matching binaries.
• The CLI reads its version from cli/deno.json (static JSON import baked
  into the compiled binary) — the manifests are the single version source;
  verified the binary reports the manifest version.

Scope confirmation

• All changed files relate to the stated purpose
• No drive-by refactors or "while I'm here" cleanups
• No formatting changes mixed with functional changes

New abstractions (if any)

None — one spec document; the publish orchestrator remains generated.

New dependencies (if any)

None (jq ships on GitHub runners).

New tests (if any)

None automated; verified: generator typechecks and regenerates idempotently
(CI staleness check), all workflow YAML parses, the compiled binary reports
the manifest version, and lint/typecheck/tests pass.

Refs #88.

[github-actions]

Release Config Files

The following is the list of files used in the release process. Update this
list when a file is added or removed.

PR #87: ci: spec-driven release process — maintainer tags, binaries gate packages

14 files, +478 / -258

Scope

🟡 736 lines changed. PRs under 400 receive more thorough review.

🟡 Large PR with no linked issue.

🟡 PR mixes config and source changes.

Structural

✅ No structural bloat detected.

Slop

Static Analysis

✅ Oxlint found no issues.

Correctness

FILE: scripts/gen-publish-workflow.md
PATTERN: TODO comment
CONCERN: Placeholder for future diff analysis not related to current release process changes
QUESTION: Is this TODO necessary for the current PR's scope?

FILE: scripts/gen-publish-workflow.md
PATTERN: Unused variable declaration
CONCERN: const changedFilePaths = pr.files.map((file) => file.path); is declared but only used in a commented-out JSX element
QUESTION: Why is this variable declared if it's not used in the current implementation?

FILE: .github/workflows/publish-packages.yml
PATTERN: Hardcoded workflow name in comment
CONCERN: Comment references publish-packages.yml directly instead of using a variable
QUESTION: Should this be parameterized for consistency with generated content?

FILE: specs/release-process-spec.md
PATTERN: TODO comment in code block
CONCERN: // TODO: evaluate whether the diff's changes are actually reflected in the spec document is a placeholder for future validation
QUESTION: Is this TODO required for the current spec completeness?

FILE: scripts/gen-publish-workflow.md
PATTERN: Unused JSX element
CONCERN: <ReleaseSpecWarning files={changedFilePaths} /> is present but not implemented
QUESTION: Why is this component included without corresponding implementation?