fix: ensure major release tags (vX) are reliably moved on publish

[d-lazenby]

Summary

Resolves Issue 53 on the CE project board (apologies: I have a problem linking to the actual issue so had to hard-code rather than link to it).

Major channel tags (v0, v1, ...) are now moved deterministically within the release pipeline instead of relying on a separate release-triggered workflow that may not fire when using GITHUB_TOKEN.

Changes

• release-please.yml: Added "Move major tag to latest stable release" step that runs after Release Please completes, using action outputs directly
• move-major-tag.yml: Converted to manual fallback with workflow_dispatch trigger for tag reconciliation if needed
• update-tf-modules.yml: Added "Resolve updater_ref to commit SHA" step to resolve tags/branches to exact commit SHAs before checkout, ensuring reproducibility and SHA-only audit trail per policy
• docs/how-to/consumer-setup.md: Added maintainer verification guidance and recovery procedures

Testing

• YAML linting: all workflows pass
• Bash logic validation: major tag extraction and SHA resolution tested locally

Testing Required Post-Merge

1. Trigger Release Please manually on main (or wait for a merged PR)
2. Verify after release is published:

   git ls-remote --tags origin "v0" "v0.*"
   # Confirm v0 exists and points to latest vX.Y.Z commit

3. Test external consumer (ons-dsc-dns or test repo):

• Call update-tf-modules workflow at @v0 without explicit updater_ref
• Verify workflow succeeds and resolver step logs exact commit SHA
• Confirm no regressions in existing workflows

Impact

• External callers using @v0 will no longer require explicit updater_ref workaround
• All tag resolution now auditable via logged commit SHAs
• Manual reconciliation available if drift occurs