fix(ci): use bun.lock for setup-bun cache key

[SergioChan]

Issue for this PR

Closes #16289

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Updates the custom setup-bun action cache key to hash bun.lock instead of bun.lockb.

bun.lockb has been replaced by bun.lock, so the previous key no longer tracked the current lockfile. This change makes cache invalidation follow actual dependency changes again.

How did you verify your code works?

• Verified the action now uses hashFiles('**/bun.lock') in .github/actions/setup-bun/action.yml.
• Confirmed no remaining bun.lockb reference in that action file.

Screenshots / recordings

N/A (CI workflow config change only).

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found:

• PR fix(ci): use bun.lock as caching key instead of deprecated bun.lockb #16291: "fix(ci): use bun.lock as caching key instead of deprecated bun.lockb"
  • fix(ci): use bun.lock as caching key instead of deprecated bun.lockb #16291

This PR appears to be addressing the exact same issue as PR #16386. Both are updating the setup-bun cache key to use bun.lock instead of the deprecated bun.lockb. You may want to check if PR #16291 is already merged or if one should be closed in favor of the other.

[SergioChan]

Thanks for the duplicate check. This PR is a narrowly scoped follow-up for #16289 on cache key usage only, switching lockfile detection from to . If maintainers prefer to consolidate into #16291, I can close this immediately.

[SergioChan]

Clarifying my previous note: this PR is a narrowly scoped follow-up for #16289 on setup-bun cache key usage only, switching lockfile detection from bun.lockb to bun.lock. If maintainers prefer to consolidate into #16291, I can close this immediately.