fix(scaffold): users service Prisma binds a stale Postgres endpoint — DB health check fails on a clean scaffold.runtime run

[rickylabs]

Filed by the 0.0.5 orchestrator from two independent reproductions in the milestone run.

Observed twice, once with zero contention:

1. Sagas slice merge-readiness run (PR fix(sagas): register KV adapter in generated runtime glue #1193 records): suite 51/1 — live Postgres on 44973, the users service's Prisma still bound to 50564 after the nominal preserve-AppHost gate.
2. Orchestrator clean rerun (2026-08-04 ~07:13Z, nothing else on the machine, fresh scaffold): suite 51/1 — users health probe: https://localhost:44903/health → fetch failed; http://localhost:3001/health → 503 {database: unhealthy, Prisma raw query failed}; http://localhost:46361/health → 200 Healthy. Two instances of the service disagree; the DB-backed one binds a Postgres endpoint that is not the live one.

Class: the connection-string/endpoint wiring for DB-backed services goes stale across AppHost allocations — sibling of #1196 (ephemeral db-operation AppHost masking) and the reason the sagas slice's earlier suite run was mis-read as environmental churn. A clean-run reproduction retires that theory: this is a product defect in scaffold DB wiring.

Acceptance

• On a fresh scaffold, the users service's Prisma endpoint matches the live Postgres allocation — health probe green on the first AppHost start, demonstrated on a clean scaffold.runtime one-pass
• The stale-write path has a RED-first test proving no persisting path exists (identification split to fix(scaffold): identify what actually persisted the stale Postgres endpoint in the #1202 reproductions #1396 by owner ruling 2026-08-09 — the mechanism originally named for it was falsified in source; see the correction comment below)
• A second consecutive AppHost start (fresh allocation, same scaffold) stays green — the re-allocation case is the trigger surface
• Verified artefact-first per the owner's standing bar (health JSON + otel evidence, not exit codes)

Refs #1196 (family), #1193 + the orchestrator run log (evidence), #1191 (the previous layer of this onion: the DB service now starts, and hits the next defect).

[rickylabs]

Third reproduction, decisive conditions: pristine main (3ff18a8ad), fully cleaned machine (all Postgres/Redis/Garnet containers removed first, including two 11-hour foreign ones — owner-authorized). scaffold.runtime fails identically: users → https://localhost:46475/health → fetch failed; http://localhost:3001/health → 503 {database: unhealthy, Prisma raw query failed}; healthy sibling on 45771. This retires the stale-container-interference hypothesis: the defect is in the scaffold's own DB endpoint wiring, reproducible on every clean run. Also note the constant: the unhealthy instance is always on the fixed port 3001 while allocated-port siblings are healthy — the stale binding likely lives in whatever pins that fixed-port instance.

[rickylabs]

Owner diagnosis (2026-08-04, from memory — to be confirmed at the Windows machine): a Windows background service (name starting "SCO…", autostarts on every Windows restart) occupies port(s) in the range the scaffold uses; WSL2's localhost forwarding makes the collision visible inside WSL. This matches the observed constant exactly: the unhealthy users instance sits on fixed port 3001 in all three reproductions while every dynamically-allocated sibling is healthy.

Scope amendment (owner direction): move the scaffold's fixed default ports to less-collision-prone allocation:

• No generated service binds a fixed low/common port (3001 et al.) by default — defaults move to a randomized high/ephemeral-range allocation, or fully dynamic with discovery via the ServiceEndpointDirectoryPort (feat(mcp): add service endpoint directory and source adapters #1194/[openapi-mcp S7] Endpoint-manifest emission from the P1-proven seam #1133 — the directory exists precisely so nothing needs a well-known port)
• The colliding Windows service + port is identified and recorded when the owner is at the machine (RED evidence: the collision reproduced with the service present, green after the port change with it still present)
• Prisma/DB endpoint wiring re-verified on a clean run: three consecutive clean scaffold.runtime one-passes green (52/52) on this machine

Scheduled: wave-4 slice, 0.0.5-canary.3 train, Sol·medium-high — it pairs naturally with S7's aspire-cli endpoint work landing the same train.