npx launcher: make 'npx @libredb/studio' start the standalone server

[cevheri]

Part of the distribution-channels epic #108.

Problem

@libredb/studio is already published to npm, but only as a library for libredb-platform. There is no way to run Studio itself from npm. A bin entry would make npx @libredb/studio the cheapest possible "try it in one command" story, next to Docker.

Proposal

• Add a bin entry to package.json pointing at a small launcher script.
• The launcher starts the Next.js standalone server (or next start against a shipped build), applying the first-run bootstrap from the zero-config issue.
• Decide how the standalone server build ships in the npm package: include the built server in the published tarball (larger package) or download a release artifact on first run (smaller package, needs network).

Constraints

• Runtime under npx is Node, not Bun: the bun:sqlite-based SQLite DB provider needs a Node fallback or a clear "SQLite provider requires Bun" message.
• Package size: the standalone build plus native drivers is large; measure before choosing the shipping strategy.
• Must not break the existing library consumption by libredb-platform (exports map, tsup dist untouched).

Acceptance criteria

• npx @libredb/studio on a clean machine (Node >= 24) starts the server and prints the URL plus first-run credentials.
• Works on Linux, macOS, and Windows.
• README gains a Quick Start section with the npx one-liner.

[cevheri]

Status: all in-repo work for this channel merged to main in PR #122 (4d66b72). This issue stays open on purpose: final acceptance happens with the first release that ships standalone artifacts (0.9.42), validated per the runbook in docs/DISTRIBUTION.md (Maintainer notes > First-release validation runbook). It closes after that live validation.

[cevheri]

Live-validated with release 0.9.42: 'npx @libredb/studio@0.9.42' on a clean environment downloaded the linux-x64 tarball from the release, verified its sha256 against SHA256SUMS, unpacked, bound to 127.0.0.1, generated first-run credentials, and a real login returned {"success":true,"role":"admin"}. All four platform tarballs plus SHA256SUMS are attached to the release by CI.

[cevheri]

Re-evaluated this channel against the current codebase (0.9.56). The 0.9.42 live validation still holds, and the launcher has been hardened well beyond the original scope since:

• Acceptance path unchanged: npx @libredb/studio downloads the platform tarball from the GitHub release, verifies it against SHA256SUMS, caches it under ~/.libredb-studio/<version>/, and starts the standalone server with zero-config first-run credentials (Zero-config first run: auto-generate JWT_SECRET and bootstrap admin credentials #109).
• Runtime floor is now a tested Node >= 20.9 with a launcher preflight and ABI guard (feat(runtime): tested Node 20.9 engines floor - launcher preflight, ABI guard, engine-matrix CI #142) - stronger than the original "Node >= 24" criterion.
• The SQLite constraint was solved properly instead of erroring out: the provider selects bun:sqlite / node:sqlite at runtime (LIBREDB_SQLITE_DRIVER override), so SQLite works fully under npx.
• Package-size dilemma resolved as "download on first run": the npm package ships only dist + bin; the standalone payload never enters the tarball, and library consumption by libredb-platform is untouched (bin/package.json scopes ESM to the launcher directory only).
• Post-closure hardening from the maintainer loop and follow-ups: payload data/ preservation across upgrades (npx launcher: --verify-cache re-extracts the payload and destroys payload/data (generated credentials wiped) #132), tarball root-dir stripping (Standalone tarball extracts into the current directory (no top-level libredb-studio-<version>/ root) #133), loopback-first bind default with explicit network opt-in (Local-first bind not enforced on direct wrapper runs: deb/rpm /usr/bin/libredb-studio and the Homebrew binary bind 0.0.0.0 #134), atomic downloads with an idle watchdog and bounded retries, --archive / --archive-sha256 / --verify-cache flags, and the post-release npx-engine-smoke workflow asserting the launcher's log-line contract.
• The channel is tracked as tier 0 / live / every-release in distribution/channels.yaml, with unit coverage in tests/unit/launcher-utils.test.ts under the 100% coverage gate.

The only remaining platform gap is Windows, deliberately descoped: the launcher points Windows users to Docker and native support is tracked in #114. Nothing left to do here - this stays closed.