TRU-342: Migrate CI/CD from Azure Pipelines to GitHub Actions

[jtcrde]

Dormant-batch of TRU-342: replaces the Azure Pipelines definition with consumers of quantum-sec/actions under the split pin policy — validation (secret-free) rides the floating @v1 major tag; the release and auto-bump workflows (secret-bearing) are exact-pinned @v1.4.0. Includes the fleet CI conventions: pull_request-only branch validation and a per-ref concurrency group.

Changes

• ci.yaml: validation (terraform-module-validation@v1), release (semantic-release@v1.4.0), auto-bump (update-source-reference@v1.4.0)
• .releaserc.json + package.json/lockfile: @quantum-sec → @cncsc release stack (semantic-release 21)
• azure-pipelines.yml deleted in the same commit (the AzDO agent's global npm-link of the old @quantum-sec semantic-release v19 conflicts with the local v21 stack — they cannot coexist)

Same changeset proven on package-pki, package-log-analytics, package-azure-networking, and terraform-azurerm-sentinel-rules — all four released and auto-bumped infrastructure-modules end-to-end on this stack.

[zhianchow]

Approving. Identical to the changeset already proven on package-pki, package-log-analytics, package-azure-networking and terraform-azurerm-sentinel-rules, and it arrives with the fleet CI conventions already folded in — pull_request-only branch validation, per-ref concurrency, and the corrected supersession comment — so there's nothing left over from the earlier reviews to re-raise.

Interfaces line up against quantum-sec/actions: validation on @v1 takes no secrets and needs no inputs; semantic-release@v1.4.0 requires GIT_TOKEN_BASIC and runs npm ci (hence the lockfile); update-source-reference@v1.4.0 requires package_name plus exactly the four secrets passed. package.json is private: true at 0.0.0-development with devDependencies identical to the proven set, all three on public npm and no .npmrc, so the registry resolves.

Because this is a dormant repo, I checked the things that only bite on a first release after a long gap:

• Tag history is compatible. 18 tags, all bare semver, latest 3.0.5. That satisfies both the strict-semver guard and — less obviously — the two-tag lookback in Determine version change, which does git describe on git rev-list --tags --skip=1. A repo with only one tag would fail that step outright; not the case here.
• No backlog to release. master sits exactly on 3.0.5 (ahead_by=0), so the first release is driven solely by this migration commit rather than by a pile of unreleased work that could produce a surprise major bump.
• The auto-bump has real work to do. package-cloudflare is referenced in infrastructure-modules (e.g. cloudflare/cloudflare-record/main.tf) pinned at ?ref=3.0.5" — the exact form the sed rewrites. This is the one that matters: if the package were no longer referenced there, the job's git commit would hit an empty index and fail under set -e, turning every post-release run red.

Parity with the deleted azure-pipelines.yml: pre-commit, Checkov soft-fail, semantic-release on master, and the infrastructure-modules auto-bump all survive. runFunctionalTests: false means no terratest to lose, and autoUpdateInfrastructureModules was left at its default, so the auto-bump job matches prior behaviour rather than adding it. No .gitmodules, so dropping submodule-init costs nothing; .terraform-version and .pre-commit-config.yaml are both present. Validating PRs is a net gain over the old pr: none.

Checks green, with release and auto-bump correctly skipped on the PR.