ci: pin github-workflows at v0.16.0, where the pin takes effect

[ExtraToast]

Until v0.15.2, the reusable workflows in github-workflows checked out their own action code with:

ref: ${{ github.job_workflow_sha }}

That context is empty inside a reusable workflow — confirmed by echoing it in a real run — so actions/checkout fell back to the default branch:

git fetch --no-tags --prune --depth=1 origin +refs/heads/main
git checkout --progress --force -B main refs/remotes/origin/main

Every pin in this repository selected a workflow file while the scripts it executed always came from main. From v0.15.2 the checkout uses a literal that release-please keeps in step with the release tag (JorisJonkers-dev/github-workflows#98), so a pin finally determines the code that runs.

Why all pins move together

They had drifted to three different versions across the service repos — v0.11.11, v0.12.0, v0.12.1 alongside v0.15.1. That divergence was invisible while everything ran main; now that pinning works it would become real, and silently different behaviour per repo is exactly what this whole change is meant to end.

Every reusable workflow interface being crossed was compared tag-by-tag against v0.16.0 — container-publish from v0.11.11/v0.12.0/v0.12.1, publish-api-clients from v0.12.1, deploy-artifact and deploy-validate from v0.15.1 — and all are identical: same inputs, same required flags, same secrets. No caller change needed.

What v0.16.0 also brings

• the self-referential checkout described above
• health.mandatory: false as an explicit opt-out for workloads with no HTTP surface
• timeouts on github-workflows' own CI and release jobs

Verification

./platform/render-local.sh run in all seven service repos against a nested context package: each derives checker 0.16.0 from these pins, renders five fragments, and passes its scorecard.