fix(deps): keep bun.lock at lockfileVersion 1 for dependabot

[Shironex]

Summary

Every Dependabot bun update run (/ and /site) has failed since the move to bun 1.4.2. This keeps both bun.lock files at lockfileVersion 1, which Dependabot can read, with no dependency resolution change, and adds a test so they stay there.

Root cause

Bun 1.4 writes "lockfileVersion": 2 for a new lockfile. Dependabot's bun updater image bundles bun 1.3.14 (ARG BUN_VERSION=1.3.14 in dependabot-core's bun/Dockerfile, MAX_SUPPORTED_LOCKFILE_VERSION = 1) and ignores packageManager (dependabot-core#15897). Since dependabot-core#15896 it rejects a newer lockfile instead of silently downgrading it, so runs 36300871692 (/) and 36300871693 (/site) both fail with:

Unsupported bun.lock 'lockfileVersion' 2 in /bun.lock. The bun version Dependabot runs supports up to 1.

Upstream: dependabot/dependabot-core#16026 (open) and dependabot/dependabot-core#16071 (open, bumps the image to bun 1.4.0 and accepts versions 2 and 3; no review yet).

Why version 1 is safe here

• Bun 1.4.2 has no flag or bunfig.toml key that writes version 1, but its writer keeps the version a lockfile was loaded with. Versions 1 and 2 hold the same content (install: bump default lockfileVersion to 2, gate stricter parse checks behind it oven-sh/bun#31539); version 2 only adds two parse checks, covered below.
• Set the field to 1, then let bun 1.4.2 re-save: every package (name@version and integrity) is unchanged, root 233 and site 380, 0 differences. Bun 1.4.2 re-saves the files byte-identical, and --frozen-lockfile passes.
• Bun 1.3.14 (Dependabot's) reads both v1 files with --frozen-lockfile and re-saves them byte-identical.
• bun add plus bun remove, and bun update, under bun 1.4.2 keep version 1.
• Rejected: letting bun 1.3.14 rewrite the v2 file. That re-resolves the root lockfile (27 packages: rollup 4.63.3 to 4.63.4 with its 25 platform packages, @types/node 22.20.3 to 22.20.4).
• Trade-off: version 1 skips two parse checks version 2 makes (an npm tarball outside the default registry must carry an integrity hash, and a git dependency's resolved tag must be a safe path; bun still checks the tag at checkout). Neither lockfile has a tarball URL or a git dependency today. CONTRIBUTING and dependabot.yml now say to review lockfile diffs for both.
• Rejected: turning off the bun entries. Bun gets Dependabot version updates but no security updates, and the dependency graph does not parse bun.lock, so that would leave no automated bun updates at all.

Changes

• bun.lock, site/bun.lock: lockfileVersion 2 to 1, exactly as bun 1.4.2 re-saved them.
• test/lockfile-version.test.ts: fails when either lockfile is not version 1, with a message saying how to restore it and when to move to 2. Checked by setting bun.lock back to 2: that test failed, the site one passed.
• CONTRIBUTING.md: the toolchain lines now say why the lockfiles stay at version 1, never to delete and regenerate one, and how to move to 2 once dependabot-core#16071 ships.
• .github/dependabot.yml: the same note, next to the bun entries.

This PR merges cleanly with #8: its site/bun.lock changes start at line 8, and the version field is on line 2.

After merge

The next scheduled (weekly) or manually triggered bun update run for / and /site should succeed. It will likely open pull requests for pending minor and patch updates (for example the rollup and @types/node patches above, grouped as configured), each keeping lockfileVersion 1. Once Dependabot runs a bun that reads version 2, set the field back to 2 in both lockfiles and update the test, CONTRIBUTING and dependabot.yml.

Test plan

• bun install --frozen-lockfile at the root and in site/ (bun 1.4.2)
• bun run typecheck
• bun run test: 22 files, 248 passed, 2 skipped (Windows only)
• bun run --cwd site test: 156 pass
• bun run docs:build