fix(self-host): apply the pglite-prisma-adapter Bytes patch on npm installs

[f-liva]

Problem

happy-server-self-host installed from npm ships an unpatched pglite-prisma-adapter, so standalone PGlite self-hosting is broken as soon as the first encrypted session exists.

The repo already has the fix — patches/fix-pglite-prisma-bytes.cjs, added in 9e99583 — but it is wired into the root scripts/postinstall.cjs:

require('../patches/fix-pglite-prisma-bytes.cjs');

That root script only runs for a monorepo checkout. Someone doing npm i -g happy-server-self-host runs packages/happy-server-self-host/scripts/postinstall.cjs, which today only does prisma generate. npm then resolves pglite-prisma-adapter@^0.7.2 fresh from the registry, unpatched — lucasthevenet/pglite-utils#50 is still open, so there is no fixed release to bump to.

Symptom

parsePgBytes returns a Uint8Array, which serializes as {"0":104,"1":101,…} across the JS→WASM boundary; the query engine wants number[]:

Invalid `prisma.session.findMany()` invocation:
Inconsistent column data: Conversion failed: expected a string or an array
in column 'dataEncryptionKey', found {"0":0,"1":73,"2":179,...}
errorCode: "P2023"   url: "/v1/sessions"   statusCode: 500

Every Bytes column is affected, which in practice means every dataEncryptionKey. GET /v1/sessions and GET /v1/machines return 500, the CLI reports Machine registration failed: 500, and no session ever appears in the app. Rows with a NULL key read fine, so a fresh server looks healthy right up to the first CLI session — then every listing containing that row fails, not just the row.

Same underlying bug as #612 and #686; this PR is about the npm distribution path specifically, which those don't cover.

Fix

Apply the same replacement from the package's own postinstall.cjs, against whichever adapter copy npm resolved for it. require.resolve('pglite-prisma-adapter', { paths: [root] }) handles hoisted and nested layouts alike (the adapter exports no ./package.json, so its entry point is resolved instead and both bundles are patched next to it).

• Idempotent — the regex no longer matches once applied, so a monorepo install that already ran the root patch is a no-op.
• Silent no-op if the adapter isn't installed, matching the existing tolerance for a fresh checkout with no prisma/schema.prisma.
• No behaviour change for monorepo users; patches/fix-pglite-prisma-bytes.cjs is left alone.

Verified

Against the real pglite-prisma-adapter@0.7.2 tarball, in a layout mirroring an npm install:

--- run 1 ---
happy-server-self-host: patched pglite-prisma-adapter Bytes handling (2 file(s))
--- run 2 (idempotent) ---
(no patch line)
--- assert ---
Uint8Array.from({ length: hexString…  → 0 occurrences (dist/index.mjs, dist/index.cjs)
Array.from({ length: hexString…      → 2 occurrences each

Two per file: parsePgBytes and normalizeByteaArray.

Separately, this same replacement applied by hand to a live deployment (happy-server-self-host 1.1.11 behind Traefik, PGlite standalone) took /v1/sessions and /v1/machines from 500 to 200, with sessions listing on the phone and no P2023 in the logs.

Note

This is a workaround for as long as lucasthevenet/pglite-utils#50 is unmerged. Once a fixed adapter ships, bumping the dependency and dropping both this and patches/fix-pglite-prisma-bytes.cjs would be the real cleanup.