chore: track bun.lock so --frozen-lockfile means something

[rahlk]

Closes #107.

CI has always run bun install --frozen-lockfile, but bun.lock was gitignored since the repo's
first commit. Bun does not fail on a merely absent lockfile — it installs and moves on — so the
flag was a silent no-op and every CI run resolved its dependencies fresh from the registry. A green
run could not tell you which versions were green, and a transitive publish between two runs changed
what was tested with no diff to show for it.

bun.lockb, the superseded binary format, stays ignored.

Verification

Behavioral, on a clean clone of this branch — not a reading of the YAML.

Before, on main (no lockfile in the checkout):

$ bun install --frozen-lockfile
250 packages installed [5.49s]
exit=0

After, on this branch, with drift introduced into package.json:

$ bun install --frozen-lockfile          # clean: succeeds, 250 packages
$ # add an undeclared dependency to package.json, then:
$ bun install --frozen-lockfile
error: lockfile had changes, but lockfile is frozen
note: try re-running without --frozen-lockfile and commit the updated lockfile

The same drift was silently installed before this change. The lockfile is also idempotent —
a second bun install reports Checked 262 installs across 251 packages (no changes).

Note

The blanket bun.lock pattern this replaces had already caused a separate bug: it swallowed
test/fixtures/artifacts-app/packages/web/bun.lock, whose three sibling lockfiles were tracked,
breaking two tests on any clean checkout. That is fixed on feat/issue-101-artifacts with a
!test/fixtures/**/bun.lock negation, which becomes redundant once this lands — worth removing
when the stack merges, since nothing ignores those paths any more.