Fix setup-bun cache key for bun.lock

[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 setup-bun action cache key to hash bun.lock (the current lockfile) instead of bun.lockb, so cache invalidation tracks the correct dependency lockfile.

How did you verify your code works?

Not run (workflow change only).

Screenshots / recordings

Not a UI change.

Checklist

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

[github-actions]

Hey! Your PR title Fix setup-bun cache key for bun.lock doesn't follow conventional commit format.

Please update it to start with one of:

• feat: or feat(scope): new feature
• fix: or fix(scope): bug fix
• docs: or docs(scope): documentation changes
• chore: or chore(scope): maintenance tasks
• refactor: or refactor(scope): code refactoring
• test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

[github-actions]

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

• Not all checklist items are checked. Please confirm you have tested locally and have not included unrelated changes.

Please edit this PR description to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[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"
  • URL: fix(ci): use bun.lock as caching key instead of deprecated bun.lockb #16291
  • Why related: Both PRs address the exact same issue - updating the setup-bun action to use bun.lock instead of bun.lockb as the cache key. This appears to be a duplicate fix for the same problem.

You should review PR #16291 to determine if it's already been merged or if one of these should be closed in favor of the other.

[SergioChan]

Thanks for the heads-up. Closing this as a duplicate of #16291 to avoid parallel fixes for the same issue.