Rectify compatibility seal for Dependabot workflow updates

[lamemustafa]

Problem

Dependabot PRs #337 and #339 update CI/security actions but leave the sealed compatibility surface stale. Required checks are red; #337 has the current P1 review finding.

Rectification scope

Create one dedicated successor PR from current master carrying both action bumps and the regenerated workflow surface. Do not amend either Dependabot branch.

Acceptance

• documented rehash-surface → seal-surface → repoint-matrix sequence under Rust 1.96
• executable compatibility gate and workflow-consistency checks
• current-head CI including required Windows/macOS native paths
• workflow rollback and migration evidence

Supersedes the merge paths for PRs #337 and #339 after publication.

[lamemustafa]

Closed by #386, now merged.

The Dependabot PR this issue was raised against has been superseded: #336, #337, #338, #339, #340, #341, #342 and #343 were consolidated into a single change so the licence regeneration and compatibility reseal happen once rather than eight times.

#386 landed with THIRD_PARTY_LICENSES_RUST.txt regenerated, THIRD_PARTY_LICENSES.txt updated, and the compatibility surface resealed in the documented order with a confirming zero-change pass. Verified on current master: corepack pnpm run license:all reports "Apache-2.0 metadata, notices, and bundle resources are consistent", "Frontend license inventory matches 5 locked components", "Rust license inventory matches 383 locked components".

The underlying cause — that the frontend inventory was hand-maintained with no generator, unlike the Rust one — is addressed separately in #390, which adds scripts/generate-frontend-licenses.mjs so a future bump regenerates instead of requiring hand-edits.