fix(scaffold): generated adapters exit with their daemon and drop abandoned calls

[TeoSlayer]

Problem

Every adapter generated from internal/scaffold/templates/main.go.tmpl has four lifecycle faults. The harness sweep found all of them in the published io.pilot.sixtyfour 0.1.0 bundles on darwin/arm64, darwin/amd64, linux/amd64 and linux/arm64. Rebuilding sixtyfour from main (fcd0b12, submissions/io.pilot.sixtyfour/case.json) reproduces them, so they come from the template, not from sixtyfour.

	Published 0.1.0 (measured)
Orphan	The only exit is SIGINT/SIGTERM. After its parent is SIGKILLed, the app is reparented to pid 1 and keeps answering IPC, on all 4 platforms. Linux daemons only catch this when built with app-store ≥ v1.0.3 (Pdeathsig); no released daemon pins that yet, and macOS has no Pdeathsig at all.
Abandoned calls	ipc.Serve runs handlers on the process ctx, so a caller that hangs up (supervisor.callFrom at its deadline, pilotctl appstore call at 120 s) doesn't cancel anything. The backend request and its 2 fds stay open until the method timeout (60 s for find_email, 280 s for the intelligence methods). darwin-arm64: 30 calls abandoned after 0.3 s took fds from 7 to 67, and the backend still served every request.
EMFILE crash	Under the Linux supervisor's RLIMIT_NOFILE=256, 121 (amd64) or 124 (arm64) abandoned calls, or 150 legitimately concurrent ones, crash the app: serve: accept: accept unix app.sock: accept4: too many open files → log.Fatalf → exit 1. Every in-flight call is lost (0/150 replies).
Socket hijack	Closing the listener unlinks app.sock by name. After a hard daemon death, stopping the old orphan deleted the socket the new instance had just bound, so calls failed with FileNotFoundError while the new instance was still running.

Fix (template only)

• watchParent: main records os.Getppid() before anything slow. A 250 ms ticker cancels the serve ctx once the parent pid changes, so the adapter shuts down the normal way (listener closed, socket removed). An adapter started with ppid ≤ 1 (for example a container's PID 1) doesn't watch.
• serveConn: a goroutine is the connection's only reader and feeds ipc.Serve through an io.Pipe. When the caller sends EOF, it cancels the call's ctx, so the backend request, or a CLI child through exec.CommandContext, is aborted immediately. None of the in-tree callers (ipc.Call, supervisor.callFrom) half-close before reading the reply.
• Accept backoff: EMFILE, ENFILE and ECONNABORTED back off from 5 ms to 1 s and keep serving, the same way net/http handles them, instead of log.Fatalf.
• Socket ownership: SetUnlinkOnClose(false), and app.sock is removed only if it's still the inode this process bound (os.SameFile).

Tests

internal/scaffold/zz_adapter_lifecycle_e2e_test.go (TestGeneratedAdapterLifecycleE2E) generates and builds a real http adapter, points it at an httptest backend, and checks:

1. It exits within 3 s of its parent being SIGKILLed and removes its socket.
2. SIGTERM to an old instance leaves a newer instance's socket in place, and the newer instance still answers.
3. A caller hanging up cancels the backend request, checked 5 times in a row.
4. Under ulimit -n 32 with 40 waiting callers, the adapter hits EMFILE (the test asserts the log line) and keeps running. It serves again once the callers hang up. On macOS the kernel drops a pending connection when accept(2) fails with EMFILE, where Linux leaves it queued, so the test tolerates a caller being turned away.

Results:

• On main all 4 subtests fail: adapter pid … still running 3s after its parent was killed (orphaned), old instance's exit removed the new instance's socket, backend request still open 3s after its caller hung up, adapter exited while out of descriptors: exit status 1.
• On this branch: macOS arm64 -race -count=10 40/40; linux/arm64 and linux/amd64 (golang:1.25.13-bookworm) -count=5 20/20 each.
• go test ./... passes on macOS. internal/scaffold and internal/publish also pass on linux/arm64.

Verified on real sixtyfour bundles (rebuilt from this branch)

I built case.json with the version bumped to 0.1.1 through publish.BuildBundle (go1.26.8, a TEST-ONLY key, nothing published) and ran the harness on every platform. darwin/amd64 ran under Rosetta, Linux in docker --init, both online and --network none:

• sixtyfour.help 200/200 on all 4 platforms, online and offline. 10,000 calls on darwin-arm64: fd 7→7, RSS levels off at 18.4 MB.
• find_email ×1000 through a local mock broker (SIXTYFOUR_BACKEND_URL): 1000/1000, fd 8→8. X-Pilot-Signature, X-Pilot-Caller and X-Pilot-Timestamp are present.
• Orphan phase without Pdeathsig: SELF-EXIT after 240–325 ms on all 4 platforms (0.1.0: ORPHAN). The Linux Pdeathsig phase still passes (1–8 ms).
• 150 calls abandoned after 0.3 s, with RLIMIT_NOFILE=256 on Linux: app fds stay at 7–9 (16–18 on amd64 under Rosetta). 150/150 upstream requests were cancelled by the app. No crash, and SIGTERM exits cleanly.
• 150 concurrent held calls with NOFILE=256: the app survives. amd64: 150/150 ok. arm64: 124 ok, and 26 got an error reply (socket: too many open files dialing the backend), so every caller got an answer. Published 0.1.0: exit 1, 0 replies. On darwin (no cap): 150/150.
• Socket race on darwin arm64 and amd64: B's app.sock survives both A's own exit and a SIGTERM to A, and B keeps serving. Published 0.1.0: app.sock exists=False … FileNotFoundError.

Not in this PR

• The supervisor's stop path still SIGKILLs the app, so app.sock stays on disk after a stop. The adapter can't clean up after a SIGKILL; the supervisor has to send SIGTERM first. Measured with the real supervisor spawn + ctx cancel on darwin-arm64, 3 rounds each: app-store main 79e9944 and fix(supervisor): stopping an app stops the processes it started app-store#39 (SIGKILL to the group) give exit=-1, app.sock left behind=true. A SIGTERM-first stop with a SIGKILL fallback, stacked on http adapter: REST path params + PATCH/PUT/DELETE + broker pattern allow-list #39, gives exit=0 after ~20 ms, app.sock left behind=false for both this build and 0.1.0. That's app-store code and is handled separately. Until it lands, the adapter and the supervisor both delete a stale socket before Listen, so nothing breaks.
• Shipping sixtyfour 0.1.1 needs the app's publisher key (ed25519:VoVCiQKPr73di2MlUd091a2Y6TCj/edSbCwRDtnYquI=), which isn't available here. Rebuilding from this commit with go1.26.8 is reproducible: the binary sha256 was identical across two builds on all 4 platforms. Note that a rebuild from current main also adds sixtyfour.balance to exposes, which comes from earlier template changes.

🤖 Generated with Claude Code