fix(ci): build the SDK types with the repo's own tsc (and pin the pantry action)

integration has been red on main since this morning, on commits that changed no dependency file.

git diff 69e01f5..b693fb0 -- '*package.json' '*bun.lock*' '*bunfig.toml' is empty. Nothing in the repo changed.

The wrong diagnosis, and what disproved it

My first commit here assumed the cause was pantry-pm/pantry/packages/action@main — a floating ref that moved from 235036fa (green) to 88dd705e (red) — and pinned it. That did not fix it. The run is worth reading: the pin took effect, the log shows Download action repository 'pantry-pm/pantry@235036fa…', and integration failed identically.

Pinning the action pins the installer, not what it installs. The same run shows it fetching:

+ typescript@7.1.0-dev.20260708.3

resolved fresh at runtime. That dev build cannot resolve its own platform binary:

Error: Unable to resolve @typescript/typescript-linux-x64.
    at getExePath (.../pantry/typescript/lib/getExePath.js:53:19)

No pin of the action would have changed that.

The actual defect

craft builds with whatever tsc is first on PATH.

packages/typescript's build:types ran bun run tsc. Locally that finds the repo's own typescript@7.0.2, because nothing shadows node_modules/.bin. In CI the pantry action installs into <repo>/pantry and puts it ahead on PATH, so the identical script silently ran a different compiler — a dev build the repo never declared.

That also explains why exactly one job went red: integration is the only job that runs bun run build in packages/typescript, and build → build:types is the only script that reaches tsc at all. typescript-sdk runs typecheck and bun test; lint runs pickier. A toolchain break surfaced in one job and looked like a code problem.

The fix

bunx --bun tsc, which resolves the local one in both places — and is the form CLAUDE.md already prescribes for pickier, so the two agree now.

Verified locally: bun run build in packages/typescript completes and emits both dist/index.d.ts and dist/index.d.cts.

The pin stays

It did not fix this, and the commit that added it claimed it would. But a third-party action referenced as @main is worth pinning for its own sake, and release.yml resolving a different action on every tag is the version of that risk that costs the most to discover. All 15 references are pinned; the Apple signing gate in release.yml is untouched — the only lines changed there are three uses: refs.

Unblocks #103.