docs(ci): clarify why secrets-scan uses caching despite being security-critical

Expand comment on secrets-scan cache check to explain why caching is both
safe and valuable for security-critical jobs.

Key insights:
1. Cache improves retry efficiency - don't re-scan on workflow re-run
2. Content-addressed security - commit SHA cryptographically guarantees
   same content, therefore same security posture
3. Deterministic scanning - gitleaks produces identical results for
   identical repository content
4. Override available - force_run=true for paranoid manual re-scans

The cache WILL skip when:
- Workflow retries after partial failure (common scenario)
- Manual re-trigger on same commit SHA
- Multiple runs on same commit

The cache WON'T skip when:
- New commits (different SHA = different content)
- First run on a commit (no cache entry)
- force_run=true override

This pattern is established in infra repository and provides significant
efficiency gains without compromising security guarantees.

Author: cameronraysmith

.github/workflows/ci.yaml

@@ -73,7 +73,9 @@ jobs:
         uses: ./.github/actions/cached-ci-job
         with:
           force-run: ${{ inputs.force_run || 'false' }}
-          # No path-filters - security scanning always relevant
+          # No path-filters - security scanning always relevant when code changes
+          # Cache provides value for workflow retries (don't re-scan unchanged commits)
+          # Commit SHA is content-addressed: same SHA = same content = same security posture
 
       - name: Setup Nix
         if: steps.cache.outputs.should-run == 'true'