TRU-342: Bump quantum-sec/actions pins to v1.4.0 / floating v1

[jtcrde]

Pin update v1.0.0 → the split policy: validation floats on @v1 (currently resolving to the v1.4.0 commit); semantic-release and update-source-reference exact-pin @v1.4.0. Retires the jq expansion bug in v1.0.0's update-source-reference (single-quoted --jq meant ${PACKAGE_NAME} never expanded in the PR-dedup query — duplicate PRs on major bumps; fixed in v1.2.2). No interface changes.

[zhianchow]

Approving. The split — @v1 for validation, @v1.4.0 for the two secret-bearing workflows — matches the policy in quantum-sec/actions#6, and v1 currently resolves to the same commit as v1.4.0 (1229f4e), so nothing changes behaviourally today beyond picking up the fixes between v1.0.0 and v1.4.0.

Confirmed the jq fix the description cites is actually in: the PR-dedup query in update-source-reference.yaml now uses a double-quoted --jq string, so ${PACKAGE_NAME} expands. Also confirmed the release chain works end-to-end from this repo — 1.1.0 released on the new stack, followed by Update package-pki references to 1.1.0 (minor) (dd14fde) in infrastructure-modules.

Non-blocking: the title and body both say v1.3.0, but the diff pins v1.4.0 — and introduces the floating @v1, which is a supply-chain posture change rather than a version bump. Worth correcting the title before merge, since that's the line that lands in the commit history.

[zhianchow]

Re-approving after the CI hygiene commit. Verified by effect, not just by diff: this PR's head now produces a single pull_request run instead of the push/pull_request pair, all checks green. Feature-branch push triggers dropped, concurrency per workflow+ref added with cancel-in-progress: false.

Two carry-over nits, neither worth holding the merge:

1. The title still says v1.3.0 while the diff pins @v1.4.0 (plus the floating @v1). That's the line that lands in the commit history, so it's the one worth correcting.
2. The concurrency comment's "superseded runs are not cancelled" isn't GitHub's behaviour — cancel-in-progress: false protects the in-progress run; a previously pending run in the group is cancelled when a newer one queues. Harmless here since semantic-release is cumulative, but the sentence is now in eleven files fleet-wide.

[zhianchow]

Re-approving after the concurrency-comment correction. Comment-only — one file, 5+/3-, no change to any YAML key — and the new wording is accurate: cancel-in-progress: false protects the in-progress run, and a superseded pending run is replaced rather than queued.

I also checked that the stated rationale actually holds for this repo, rather than taking it as boilerplate: validation here runs pre-commit run --all-files over the full tree, and releases are cumulative, so a surviving run genuinely does cover a replaced one's content. Checks green on the new head.