fix(ci): use full URL for ClusterFuzzLite storage-repo

[mpjunior92]

Summary

ClusterFuzzLite's push-fuzzing, batch-fuzzing, and prune jobs all pass storage-repo: \${{ github.repository }} directly to the run_fuzzers action. That expression resolves to the path-style string `Layr-Labs/eigenx-kms-go`. Internally the action runs git clone <storage-repo> ., which interprets a bare path as a local directory and bails with:

```
fatal: repository 'Layr-Labs/eigenx-kms-go' does not exist
```

This causes the `push-fuzzing` job to fail at the "Run fuzzers" step on every push to master (example failing run). The same code path is hit by `batch-fuzzing` (scheduled daily) and the manual `prune` job.

Fix

Per the official ClusterFuzzLite docs, `storage-repo` must be a full HTTPS URL with an auth token:

```yaml
storage-repo: https://${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}.git
```

Applied to all three jobs that use it.

Notes

• The corpus storage branch `clusterfuzz-corpus` doesn't exist yet on origin (only `clusterfuzzlite-backup` does). The action will create the branch on first successful push, so no manual seeding required.
• `pr-fuzzing` doesn't use `storage-repo` at all, so it's unaffected (and has been passing).

Test plan

The fix is mechanical (copy from the official docs), but verification can only happen in CI:

• Merge triggers `push-fuzzing` on master; "Run fuzzers" step should succeed and create/push to `clusterfuzz-corpus` branch.
• Subsequent push runs reuse the corpus instead of cloning a missing repo.

[claude]

Claude finished @mpjunior92's task in 59s —— View job

---

Code Review

• Read changed file and diff
• Analyze correctness, security, and completeness

---

Summary

This is a minimal, well-targeted fix that correctly addresses the root cause: ${{ github.repository }} resolves to a bare path (Layr-Labs/eigenx-kms-go) which git clone cannot interpret as a URL. The change applies uniformly to all three affected jobs.

---

Correctness ✅

The fix matches the official ClusterFuzzLite docs exactly. All three jobs that use storage-repo are updated:

• batch-fuzzing (line 118)
• push-fuzzing (line 159)
• prune (line 198)

The pr-fuzzing job correctly has no storage-repo parameter and is unaffected, as noted in the PR description.

---

Security: Token in URL ⚠️ (acceptable, standard pattern)

Embedding GITHUB_TOKEN in a URL (https://${{ secrets.GITHUB_TOKEN }}@github.com/...) is the prescribed pattern for this action. A few things worth knowing:

1. GitHub automatically redacts GITHUB_TOKEN in workflow logs, so the full URL won't appear in CI output.
2. The token is ephemeral — it expires at the end of the workflow run and is scoped only to this repository.
3. The affected jobs already declare permissions: contents: write, which is the minimum needed for corpus pushes. No privilege escalation.
4. The token could persist in the runner's git credential store or .git/config within the ephemeral container, but GitHub-hosted runners are destroyed after each job, so this is a non-issue.

No action needed — this is the expected and officially documented approach.

---

Minor Observations

• The prune job ends the file without a trailing newline after storage-repo-branch: clusterfuzz-corpus — this pre-existed and is not introduced by this PR.
• push-fuzzing uses mode: batch (not a dedicated push mode). This appears intentional given the 30-minute window and corpus-building intent; no change needed.

---

Verdict

LGTM. The fix is correct, minimal, and consistent with upstream docs. Once merged, push-fuzzing should succeed and create the clusterfuzz-corpus branch on first run.