[plan] Fix cache poisoning vulnerabilities in release workflow

[github-actions]

Objective

Fix High-severity cache poisoning vulnerabilities in the release.lock.yml workflow.

Context

Security Risk: Cache poisoning allows attackers to inject malicious content into the build cache, leading to compromised build artifacts or supply chain attacks.

Affected File: .github/workflows/release.lock.yml

• 2 occurrences at line 318 (workflow level)

Reference: Discussion #5202 - Static Analysis Report

Approach

Implement cache key validation and restrict cache access scope.

Recommended Fixes

1. Use more specific cache keys:

   • Include commit SHA or branch name in cache key
   • Avoid overly broad cache key patterns

2. Restrict cache scope:

   • Use restore-keys carefully - avoid wildcard patterns
   • Consider branch-specific caching

3. Validate cache integrity:

   • Add checksum verification for cached artifacts
   • Implement cache validation steps

Files to Modify

1. .github/workflows/release.md (source workflow)

   • Review cache configuration in frontmatter
   • Update cache keys to be more specific
   • Restrict restore-keys patterns

2. Recompile workflow:

   gh aw compile release

Example Fix

❌ Before (Vulnerable):

cache:
  key: build-cache
  restore-keys: |
    build-

✅ After (Secure):

cache:
  key: build-cache-${{ github.sha }}
  restore-keys: |
    build-cache-${{ github.ref_name }}-
    build-cache-main-

Acceptance Criteria

• Cache keys include specific identifiers (commit SHA, branch, or version)
• Restore-keys patterns are restricted and specific
• Cache validation steps added (if applicable)
• Workflow compiles successfully with gh aw compile release
• Static analysis (zizmor) shows no cache poisoning findings
• Release workflow still functions correctly

Validation

Run static analysis to verify fix:

gh aw compile release --zizmor

Expected: No High-severity cache poisoning findings.
Related to #5207

AI generated by Plan Command for discussion #5202