fix(ci): deduplicate the mcp-publisher version pin into one composite action

[cdeust]

Defect

ci.yml pinned mcp-publisher at v1.7.9 (with its checksum); Release.yaml
independently pinned v1.8.1 (different checksum). Two pins of the same
binary in one repo, already drifted apart — whoever bumps one has no way
to know the other exists.

Fix

.github/actions/install-mcp-publisher/action.yml — a composite action
whose version/sha256 inputs are defaulted, not passed by callers.
That means the pin lives in exactly one file; a future bump is one edit
that reaches every workflow that uses the action. Both ci.yml and
Release.yaml now install mcp-publisher through it, with no with:
override for version/checksum.

Which version, and why

v1.8.1 — Release.yaml's existing value, confirmed as the registry's
current releases/latest via its GitHub API, and its sha256
independently re-derived locally from the published release asset
(a06c9096dcb9727c13555b6be26c7effa707b01f06a4c561ba7a3635443cf2cc,
matches exactly — not trusted blindly). ci.yml's stale v1.7.9 is the one
that moves.

Verification

• python3 -c "import yaml; ..." — both workflows + the action parse.
• actionlint .github/workflows/ci.yml .github/workflows/Release.yaml —
  clean.
• Gate: grep -rn "version:\|sha256:" .github/workflows/*.yml returns
  nothing — neither workflow caller passes the pin anymore; it exists only
  as the two default: lines in the composite action.

Scope

This PR only deduplicates the pin. It does not touch what ci.yml's
validate step does — that's the separate, stacked
agent/ci-offline-registry-validate (targets this branch), which removes
the live-network dependency from the check itself.

Co-Authored-By: Claude noreply@anthropic.com

[cdeust]

ZETETIC-REVIEW: APPROVE

One binary, two independent pins in one repository, already diverged: ci.yml at v1.7.9, Release.yaml at v1.8.1, each with its own checksum. Whoever bumped one would not have known the other existed — and that is not hypothetical, since they had already drifted a full minor apart before anyone looked.

The version was chosen, not defaulted. v1.8.1 was confirmed as the registry's actual releases/latest through its GitHub API, and its sha256 was independently re-derived from the published asset rather than copied from the existing pin. It matched. Re-deriving a checksum instead of trusting one already in the tree is the difference between a pin and a rumour: a hash copied forward without verification has never been checked by anyone.

The duplication is fixed at its cause, not aligned. .github/actions/install-mcp-publisher/action.yml holds version and sha256 as defaulted inputs that no caller passes — confirmed by grep across both workflows. So the pin exists in exactly one file and a future bump is one edit that reaches everything. Aligning ci.yml onto Release.yaml would have fixed today's divergence and left the mechanism that produced it fully intact.

The stacking judgement is the part worth crediting. The report says plainly that the two defects are not fully independent: making the CI check offline removes ci.yml's need for mcp-publisher at all, which would have dissolved the pin problem as a side effect if the two had been bundled. That is a real observation about the work, and delivering them stacked — dedup first, offline validation on top — keeps each reviewable on its own merits rather than letting one silently absorb the other. #141 then reuses this action instead of introducing a third pin.

actionlint clean, YAML parses, uv sync --locked consistent. All checks green at cf8fefe.

Merging. #141 retargets to main afterwards.