🐛 keep the admission advisory-lock key valid PostgreSQL text

[jrosseel]

What broke

On testv4, every message sent to an Agent session failed with "OpenCrane could not complete that action. Try again." The API returned 503 on every POST /api/v1/me/conversations/{id}/messages.

Server log from the live silo:

operation: conversation.message.submit
Raw query failed. Code: 22021.
Message: ERROR: invalid byte sequence for encoding "UTF8": 0x00
  at PrismaRunAdmissionRepository.admit -> _admit -> $queryRaw
failureKind: transaction_failed

Cause

Both admission paths serialise one idempotency key with an advisory lock, joining the silo and the key with a NUL byte before hashing:

Prisma.sql`SELECT pg_advisory_xact_lock(hashtextextended(${siloId + NUL + key}, 0))`

PostgreSQL text cannot hold a NUL byte — the parameter fails the statement with SQLSTATE 22021, the transaction rolls back, and admission reports transaction_failed. This affected prisma-run-admission-repository.ts and prisma-child-run-reservation-repository.ts, so both agent-session sends and child @agent runs were dead against a real database.

What changed

• One __AdmissionLockKey helper composes the key, prefixing the pair with the silo's length. Distinct pairs stay distinct without reserving a character either part may legitimately contain, and no byte PostgreSQL rejects is used.
• Both call sites use it, so the composition cannot drift between them.

Verification

The existing suites stub $queryRaw, which is exactly why a NUL reached production. So both repository suites now assert that no text parameter handed to Postgres carries a NUL, plus a unit suite for the helper covering NUL-freedom, injectivity, and stability.

Proof the tests catch the regression — restoring the old separator:

src/__tests__/admission-lock-key.test.ts (3 tests | 1 failed)
Test Files  2 failed | 21 passed (23)
     Tests  2 failed | 142 passed (144)

With the fix: 23 files, 144 tests pass. nx lint clean, agent-style-check.sh 0 errors.

Not covered

No test exercises these repositories against a real PostgreSQL, so a statement-level SQL error of a different kind would still reach a cluster before CI catches it. Worth a follow-up: a Prisma integration harness against the database job's Postgres service.

Review order

Single PR, no stack. Independent of #687.