fix: run the local Composer bin with bun run --bun so the converge child runs under Bun too

[kristof-siket]

Why

With v1.4.0 the action runs the repo's local Composer bin as bun /abs/path/node_modules/.bin/prisma-composer. That runs the Composer CLI under Bun, but the converge child Composer spawns still ran under Node — and failed on the generated import … from "./service.js" (Node cannot map it to service.ts; Bun can).

The child is a #!/usr/bin/env node launcher (node_modules/.bin/alchemy) that switches to Bun only when Bun announced itself through npm_config_user_agent / npm_execpath. Bun sets those for bun run <bin>, bunx, and a relative node_modules/.bin/<bin> path, but not for an absolute file path — the shape the action used.

Observed on a stock Next.js repo: kristof-siket/next-stock run 32251429621 — composer=local bin (bun) followed by (node:2461) … Cannot find module '…/service.js' imported from …/module.ts.

What

The local-bin branch of selectComposerCommand now returns bun run --bun prisma-composer (the action already runs with cwd = working directory). --bun puts a node → bun shim first on PATH, so the CLI and every process it spawns run under Bun, independent of the launcher's detection. The bunx fallback branch already had --bun and is unchanged.

how the CLI is started	CLI	converge child
bun /abs/…/prisma-composer (v1.4.0)	bun	node ✘
bun run prisma-composer (no --bun)	node ✘	bun
bun run --bun prisma-composer (this PR)	bun	bun ✔
bunx --bun -p @prisma/composer-cli@… prisma-composer (fallback)	bun	bun ✔

Verified locally with Composer 0.9.0 by spawning the launcher the way Composer does under each shape; argument passthrough (deploy module.ts --stage …) checked. The real end-to-end proof is the next-stock rerun after v1 moves.

Release

Tag v1.4.1 and move v1 after merge. No change needed to generated workflows: they already add oven-sh/setup-bun@v2 before this action.