fix(cache): disable setup-bun cache to avoid 5-retry HTML-error burn

[MukundaKatta]

Why

Closes #1252.

anthropics/claude-code-action@v1's post-job cache save fails consistently on every second-and-subsequent run against the same PR ref. From the issue:

Attempt 1 of 5 failed with error: Unexpected token '<', "<!DOCTYPE "... is not valid JSON. Retrying request in 3000 ms...
Attempt 2 of 5 failed with error: Unexpected token '<', "<!DOCTYPE "... is not valid JSON. Retrying request in 5276 ms...
...
Warning: Failed to save: Failed to FinalizeCacheEntryUpload: Failed to make request after 5 attempts

Root cause: oven-sh/setup-bun@v2.2.0's post step calls @actions/cache.saveCache with a deterministic key derived from the Bun download URL (bun-<hash>). The key is identical across runs, so on every PR re-push the GitHub cache API rejects the duplicate key+ref with a 409 (HTML body). @actions/cache@5.x treats the unparsable response as transient and burns ~20-30s on 5 retries before surfacing a warning. The cache key isn't ref-aware and setup-bun doesn't expose a way to override it, so the issue is unavoidable as long as the cache is enabled.

This burns ~20-30s of wallclock per PR push after the first, plus persistent warning noise that masks real cache issues. See #1252 for the full repro and cache-entry inspection.

What

Pass no-cache: true to oven-sh/setup-bun in both action.yml and base-action/action.yml. The 35 MB Bun binary downloads from bun.sh in 2-3s on GitHub-hosted runners (curl install also relies on this in PR #819), so disabling the cache is a net wallclock win and removes the warning entirely.

This is the smallest action-side fix — alternatives would require either patching setup-bun upstream (issue author's option 2) or replacing it with curl-based install (issue author's option 4 / open PR #819, which targets a separate GHES bug).

Tested

Manual verification only — the change is YAML-only inside the composite step, and there are no unit tests for action.yml in test/ (tests cover TypeScript logic).

To verify after merge, run the action twice on the same PR ref and confirm:

• The "Attempt 1 of 5 failed" warning no longer appears in the post-step.
• The Install Bun step prints Downloading a new version of Bun on every run instead of Using a cached version of Bun.
• Total Install Bun step time stays within a few seconds.

[ndrc81]

Approving this fix from a downstream-user perspective. We use claude-code-action@v1 in two workflows on a private repo (Claude Code Review and Adversarial Security Review), running on every PR per project policy. Each PR push burns approximately 5 minutes on the setup-bun post-step retries described in #1252, plus warning noise that masks real cache issues. At our current PR volume that pushes us to roughly 95% of the GitHub Team plan's 3000 min/month included allowance, with the burn entirely attributable to this bug.

The action-side fix here (no-cache: true on oven-sh/setup-bun) is the minimum-surface change and avoids the larger refactor of patching setup-bun upstream or migrating to a curl-based install. The 35 MB Bun binary downloads in 2-3s on GitHub-hosted runners, so the disabled-cache wallclock is a clear net win against the 20-30s of failing-retry burn on the current path. Confirming the YAML change is contained to the two action.yml files and does not change any TypeScript logic.

No additional regression risk we can identify. Strongly support merge.