refactor(ci): the manifests subject name is written out eight times across two files #2937

🤖 Generated by the Agentic Engineer

Evidence

ghcr.io/devantler-tech/platform/manifests is hardcoded seven times in
.github/actions/deploy-prod/publish-platform-manifests/action.yml — lines 46, 47, 105, 114, 125,
135 and 162 — and an eighth time as the fallback default in
scripts/verify-published-evidence.sh.

Surfaced by a CodeRabbit finding on #2930, which caught one specific consequence: the evidence gate
was relying on its own script default matching the literal the attestation steps publish under. That
one coupling is fixed in #2930 (the value is now passed explicitly, with a test asserting the two are
equal). The remaining seven copies are untouched.

Problem

Every copy is a place a package rename, registry migration, or repo move has to be applied by hand,
with nothing checking they stayed in agreement. The copies are not interchangeable either — they feed
different mechanisms (staging tag construction, cosign signing, SBOM input, two attestation subjects,
the promotion target), so a partial rename produces a plausible pipeline that signs one reference,
attests another, and promotes a third.

Expected

The subject name is defined once in the action and referenced everywhere else, so a rename is a
one-line change and disagreement is structurally impossible rather than merely unlikely.

Acceptance criteria

• The literal appears exactly once in action.yml; every other use references it.
• scripts/verify-published-evidence.sh is always given the value explicitly; its fallback
  default is removed or made a hard failure, so an unset value cannot silently resolve to a guess.
• A test asserts the single-definition property — i.e. it fails if a second literal reappears.
• Behaviour is unchanged: the existing test-verify-published-evidence.sh suite passes unmodified.

Size

Small. Behaviour-preserving refactor, one action plus one script. Deliberately kept out of #2930,
which is a feature change — the contract forbids mixing a refactor with a behaviour change.