Fix stale comments in release-pipeline scaffolding

Three documentation-drift findings from Copilot reviewer on PR #160,
all in code introduced earlier in the same PR:

- scripts/verify-changelog.ts: header comment claimed the TypeScript
  client had no per-tag GitHub Actions workflow and verify-changelog was
  the only enforcement. That was true mid-PR; the final PR adds
  publish-typescript.yml (GHA -> ADO bridge) plus verify steps in the
  ADO pipeline.yml itself. Replace the comment with the actual
  defense-in-depth picture: every per-tag workflow + the ADO pipeline +
  ci.yml all re-run this script.

- .github/workflows/publish-spec.yml: comment said a re-pushed tag
  cancels the in-flight run, but cancel-in-progress is set to false
  precisely so we don't abort a half-finished GitHub Release upload.
  Rewrite the comment to explain the actual queueing behaviour and why
  it's deliberate.

- scripts/read-protocol-versions.ts: JSDoc described a hard-coded
  fallback when the registry source file isn't in the project. The
  implementation throws instead. Rewrite the JSDoc to match: throws on
  missing source file, missing constants, or order-invariant
  violations, and callers building a partial ts-morph project must
  include types/version/registry.ts.

No behaviour change. typecheck, lint, verify:release-metadata, and
verify:changelog all still green; YAML still parses.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: colbylwilliams

.github/workflows/publish-spec.yml

@@ -20,8 +20,10 @@ on:
 permissions:
   contents: read
 
-# Only one spec publish per tag may run at a time. A re-pushed tag (or a
-# manual re-trigger) cancels the in-flight run before publishing.
+# Only one spec publish per tag may run at a time. `cancel-in-progress:
+# false` is deliberate — a re-pushed tag (or a manual re-trigger) queues
+# behind the in-flight run rather than aborting it, so we never interrupt
+# a half-finished GitHub Release upload.
 concurrency:
   group: publish-spec-${{ github.ref }}
   cancel-in-progress: false

scripts/read-protocol-versions.ts

@@ -26,9 +26,10 @@ export interface ProtocolVersions {
 
 /**
  * Read the protocol version constants from `types/version/registry.ts`.
- * Falls back to a single hard-coded version only when the source file
- * cannot be located in `project` (e.g. unit tests with a partial
- * project), so callers don't need a runtime null-check.
+ * Throws if the registry source file is not present in `project`, or if
+ * either constant is missing, malformed, or violates the ordering
+ * invariant. Callers building a partial ts-morph project must include
+ * `types/version/registry.ts` among the source files.
  */
 export function readProtocolVersions(project: Project): ProtocolVersions {
   const sf = project

scripts/verify-changelog.ts

@@ -9,10 +9,13 @@
  *  - `verify-release-metadata` cross-checks the *current* package
  *    version against the generated constants and the metadata file.
  *  - `verify-changelog` checks that whenever someone bumps a version
- *    they also rotate the CHANGELOG. Most useful for the TypeScript
- *    client which publishes through an ADO pipeline (no per-tag
- *    GitHub Actions workflow), so this CI check is the only enforcement
- *    of the "no release without a changelog entry" invariant.
+ *    they also rotate the CHANGELOG. Every per-tag publish workflow
+ *    (`publish-spec.yml`, `publish-rust.yml`, `publish-kotlin.yml`,
+ *    `publish-swift.yml`, `publish-typescript.yml`) and the TypeScript
+ *    ADO `pipeline.yml` re-run this script as a release-time gate, on
+ *    top of the same check in `ci.yml` for every PR. Defense in depth:
+ *    a release artifact can't ship with a missing CHANGELOG heading
+ *    regardless of which entry path triggered the publish.
  *
  * The check is intentionally lenient about the rest of the heading line
  * (e.g. ` — YYYY-MM-DD` or ` — Unreleased`) — only the version-bracket