ci: pin npm to 11.x, move release-please to the GitHub App, gate publish on tests

[jbiskur]

The publish path is broken right now

build.yml sets up node 20, then runs:

- name: Update npm to latest
  run: npm install -g npm@latest

npm@latest is currently 12.0.2. Its engines:

"engines": { "node": "^22.22.2 || ^24.15.0 || >=26.0.0" }

Node 20 satisfies none of those. The release job installs an npm that cannot run on the node the job just set up.

flowcore-sdk already hit this and pinned 11.x, with the reason in a comment. hono-api was left on @latest.

This matters immediately: release-please has 0.4.1 in flight carrying the JWKS fix from #41. On the release: published event this job runs, and the fix does not reach npm.

This path has never survived a real release event

Run	Trigger	Result
28750934156	release: published v0.4.0	❌ npm error code ENEEDAUTH
28751058175	workflow_dispatch	❌ npm error 404 PUT /@flowcore%2fhono-api … or you do not have permission
28751437206	workflow_dispatch	✅ succeeded only after npm-side trusted-publisher setup

v0.4.0 reached npm by manual retry, not by the pipeline.

Changes

1. Pin npm@11 — the fix for the above, with the engine constraint written into the comment so nobody restores @latest.

2. Migrate release-please from the shared PAT to the Flowcore Release Bot App.

release-please.yml still used secrets.FLOWCORE_MACHINE_GITHUB_TOKEN. The org migration to actions/create-github-app-token — done to stop every repo sharing one PAT's 5k req/hr limit — skipped this repo.

Verified both credentials are org-scoped and reachable here:

RELEASE_PLEASE_APP_ID          visibility: all
RELEASE_PLEASE_APP_PRIVATE_KEY visibility: all

Also adds permissions: contents: read, which the workflow did not declare at all.

3. Run the tests before publishing. The release path ran deno lint only. A green PR was the last gate before npm and jsr. Now deno test -A runs before either publish step.

4. Add typecheck to the PR workflow. deno task typecheck existed in deno.json and nothing ever called it.

5. Drop sergeysova/jq-action@v2 for a one-line jq call. That removes an unpinned third-party action from the release path, and it was only reading one field from a JSON file.

6. SHA-pin the remaining actions instead of floating tags, matching flowcore-sdk.

Verification

Every CI step run locally against this branch:

### deno install --frozen-lockfile   ok
### build-npm                        [dnt] Complete!
### deno lint                        Checked 25 files
### deno fmt --check                 Checked 27 files
### deno task typecheck              ok
### deno test -A                     ok | 7 passed (121 steps) | 0 failed

All three workflow files parse as valid YAML.

What this PR does not do

The actions/checkout steps in build.yml and validate.yml still use FLOWCORE_MACHINE_GITHUB_TOKEN. That matches flowcore-sdk, and the org migration only targeted the release-please token. Left alone deliberately.

The npm publish itself cannot be proven green until a release event fires, because the job runs only on release: published or workflow_dispatch. The engine mismatch is arithmetic on published metadata rather than a guess, but the first real proof will be the 0.4.1 release.

🤖 Generated with Claude Code