fix(ci): ask pantry for a bun range it can actually satisfy

publish-commit fails intermittently with no commit in between:

Required system package bun@^1.3.14 failed to install:
No version of bun.sh satisfies "^1.3.14" (checked 139 versions, newest 1.3.11)

Why

deps.yaml declares bun: ^1.3.14 (from c6084b5, Jul 15). Pantry's newest bun.sh is 1.3.11 — verified in ts-pantry 0.11.29's own package data (dist/packages/bunsh.d.ts tops out at 1.3.11), and 0.11.29 is the newest release on npm. So no current pantry can satisfy the range. It is well-formed and unsatisfiable.

Why it looked random

The action only evaluates this spec on its reconcile path:

Cache hit — reconciling system deps against lock/spec: bun@^1.3.14, ...
Installing bun.sh@^1.3.14 via pantry SDK (from deps spec)   -> fails

When it takes the shortcut instead (Installing bun.sh@latest ... (defaulted to latest)) the range is never checked and the job passes. So the outcome tracks cache state, not the commit. Three runs today make that concrete — same deps.yaml byte-for-byte on all three branches:

This is latent on main right now, not specific to any branch.

Fix

^1.3.11 is satisfiable today and still accepts 1.3.14 the moment pantry publishes it, so this does not pin the project back.

One thing worth your call

The project develops on bun 1.3.14 while this job can only obtain 1.3.11. If the build genuinely needs 1.3.14, the real fix is upstream — pantry has to publish it — and no value in this file unblocks that. I have kept this to "make CI deterministic again" rather than assume the bump in c6084b5 was arbitrary; if it was deliberate for a 1.3.14 feature, say so and I will chase the pantry side instead.

This is also the second distinct way this file has taken down publish-commit in four days (0671de8 was the unresolvable-latest one), which is more evidence for the pinning question raised in #1103 — an unreviewed upstream is deciding when our CI works.

🤖 Generated with Claude Code