bun: support bun.lock lockfileVersion 2 and 3

[Marukome0743]

What are you trying to accomplish?

Fixes #16026.

Bun 1.4.0 writes bun.lock lockfileVersion 2 by default (oven-sh/bun#31539), and 3 for projects that use nested or version-scoped overrides (oven-sh/bun#38333). The updater image bundles bun 1.3.14, which reads only v1.

#15896 stopped bun silently downgrading those lockfiles, by rejecting anything above MAX_SUPPORTED_LOCKFILE_VERSION with DependencyFileNotSupported. That was the right trade at the time, but it means every repository that has regenerated its lockfile with 1.4 now gets no bun updates at all — the state reported in #16026. Reproduced against a real repository with a v2 lockfile:

=> parsing dependency files
An error occurred: Dependabot::DependencyFileNotSupported,
Unsupported bun.lock 'lockfileVersion' 2 in /bun.lock. The bun version Dependabot runs supports up to 1.

This is the follow-up #15896 said it would need: "at bun 1.4 GA, ARG BUN_VERSION and MAX_SUPPORTED_LOCKFILE_VERSION must be bumped together."

• ARG BUN_VERSION 1.3.14 → 1.4.0
• MAX_SUPPORTED_LOCKFILE_VERSION 1 → 3
• The unsupported_lockfile_version fixture moves to v4 so the guard still guards, and simple_v2 / simple_v3 fixtures cover the two formats that are now accepted.

Anything you want to highlight for special attention from reviewers?

The ceiling is 3, not 2. 1.4's default is 2, but a project using nested ({"node-fetch": {".": "1.7.3", "encoding": "0.1.13"}}) or version-scoped ({"ansi-styles@^4.1.0": "4.2.1"}) overrides gets 3, and the lockfile grows a top-level overrides object. Stopping at 2 would leave those repositories broken in exactly the way #16026 describes. Measured with 1.4.0:

lockfile written by	plain project	nested / version-scoped overrides
bun 1.3.14	1	1 (overrides silently dropped)
bun 1.4.0	2	3

No parser change is needed. v1 and v2 lockfiles generated from the same manifest are byte-identical apart from the version number — the packages tuple shape is unchanged. v3 only adds the overrides object, which BunLock#dependencies ignores; simple_v3 is a real 1.4.0-generated lockfile that covers it.

This does not churn anyone's lockfile format. bun 1.4 leaves an existing v1 lockfile at v1 through both install and add, and still upgrades v0 → v1 exactly as 1.3.14 did. Running the updater's own command inside the new image against a real v2 lockfile leaves it at v2:

$ bun install --save-text-lockfile --ignore-scripts   # bun 1.4.0, image-bundled
  "lockfileVersion": 2,      # unchanged

A behaviour change reviewers should know about, deliberately not addressed here. In 1.4, bun update <name> re-resolves transitive packages within the parent's range instead of hoisting the dependency to the top level. For a transitive ansi-styles behind chalk@4.1.0 (^4.1.0):

	resulting lockfile	package.json
bun 1.3.14	ansi-styles@7.0.0, outside the parent range	gains "ansi-styles": "^7.0.0"
bun 1.4.0	ansi-styles@4.3.0	untouched

SubdependencyVersionResolver#run_bun_updater keeps only the lockfile and discards the manifest, so today it can emit a lockfile pinning a version the manifest never asked for. 1.4 fixes that, but it changes which version subdependency updates land on. The existing spec stubs run_bun_command entirely, so CI does not exercise this either way; I left it alone rather than widen this PR.

Also out of scope: in 1.4 a project's bunfig.toml takes precedence over .npmrc for the same key (oven-sh/bun#38333), which can affect repositories relying on the .npmrc that FileUpdater::NpmrcBuilder writes for private registry credentials. Happy to file that separately if you'd like it tracked.

No github/docs PR. supported-package-managers.md lists Bun as >=v1.1.39 and does not name the bundled version, so the documented support range is unchanged.

How will you know you've accomplished your goal?

All of the below ran inside ghcr.io/dependabot/dependabot-updater-bun built from this branch (bun 1.4.0).

• bun suite: 383 examples, 0 failures. As a control, the suite at HEAD (ceiling 1, spec/fixtures unchanged) against the same bun 1.4.0 image is 381 examples, 0 failures — so the binary bump alone causes no regression, and this branch only adds the two new examples.
• The guard still guards. unsupported_lockfile_version is now v4, so the DependencyFileNotSupported example still fails if the ceiling is raised past 3. Conversely, the new simple_v2 / simple_v3 examples fail with the old ceiling of 1, so they exercise the change rather than passing incidentally.
• End to end. bin/dry-run.rb bun <repo> against a repository with a v2 bun.lock fails at "parsing dependency files" with the error quoted above before this change, and completes ("Dry-run completed successfully", 29 dependencies checked) after it.
• rubocop clean on bun/lib and bun/spec. bun/spec/ is excluded from sorbet/config, and the only production change is an integer constant and its comment.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[luizsignorelli]

thanks for working on it @Marukome0743. We just moved to bun 1.4 and would be nice to have dependabot working