feat(release): publish ck as @beaconbay/ck-search on npm

[runonthespot]

Summary

Adds the second distribution channel asked for in the original release plan: `npm install -g @beaconbay/ck-search` for users who don't have Rust installed.

How it works

• `package.json` declares `@beaconbay/ck-search` with a postinstall script and the `ck` bin entry pointing to a thin JS wrapper.
• `scripts/install.js` runs on `npm install`: detects platform, builds the matching GitHub release asset URL (`ck-X.Y.Z-.{tar.gz|zip}`), downloads + extracts into `dist/bin/`. Falls back to `cargo build` if invoked from a checkout (the published tarball deliberately doesn't ship Rust source, so the fallback is realistic only for local installs).
• `cli/ck.js` is a thin `spawn` wrapper that runs `dist/bin/ck` with inherited stdio.
• `scripts/test.js` is the postinstall smoke test (`npm test`).
• `.npmignore` restricts the published tarball to just `cli/`, `scripts/`, `package.json`, `README.md`, `LICENSE-*`.

`release.yml` changes

• New `publish-npm` job after `build-release`. Version is single-source-of-truth: the workspace `Cargo.toml` version + the git tag are the gate. The job runs `npm version --no-git-tag-version` to stamp `package.json` at publish time — maintainers never have to bump `package.json` manually.
• Idempotent (skips publish if `@beaconbay/ck-search@X.Y.Z` already exists on npm).
• `finalize-release` now waits on both `publish-crates` and `publish-npm`.

New repo secret required

• `NPM_TOKEN` — npm automation token with publish access to the `@beaconbay` scope. Without it the job fails fast with `::error::NPM_TOKEN repo secret is not set` (same fail-loud pattern as `CARGO_REGISTRY_TOKEN` in PR fix(deps): pin ort to =2.0.0-rc.11 so cargo install doesn't break #116).

Validated locally against the live 0.7.7 release

• `npm pack --dry-run` → clean 15 kB tarball, 7 files (`cli/ck.js`, `scripts/install.js`, `scripts/test.js`, `package.json`, `README.md`, `LICENSE-MIT`, `LICENSE-APACHE`)
• `node scripts/install.js` → correctly detected `aarch64-apple-darwin`, downloaded + extracted from GH release
• `node cli/ck.js --version` → prints `ck 0.7.7`
• `node scripts/test.js` → `✓ ck binary works: ck 0.7.7`

Origin

These files are a re-pickup of the abandoned `feature/npm-distribution` branch from October 2025 (four commits by @runonthespot — 9b20ae0, cff3623, 5a53b72, 40e3d01). The branch was too far behind `main` to rebase cleanly, so I ported the files verbatim onto current `main` with these adjustments:

• `package.json` version bumped from stale `0.7.0` to current `0.7.7`
• Removed dead `"main": "index.js"` (no such file exists)
• Workflow rewritten to auto-stamp package.json version from Cargo.toml at publish time, rather than requiring both to be hand-kept in sync

Test plan

• `npm pack --dry-run` clean
• `node -c` syntax check on all 3 JS files
• Full install flow against live 0.7.7 GH release
• `cargo fmt --check` clean
• CI green on this PR
• After merge: set `NPM_TOKEN` secret, cut 0.7.8, verify first npm publish

Out of scope (follow-ups)

• The `buildFromSource` cargo fallback path in `install.js` can never fire from a published npm tarball (Rust source is excluded). Could either remove it or improve the error message to point out it's checkout-only. Left as-is to match the original.
• Linux `aarch64` is not currently built by `release.yml`; npm install on that target falls through to the cargo fallback and fails. Worth adding the target separately.

🤖 Generated with Claude Code