harper.js dev survives SIGKILL of its parent (reparented to PID 1, quiet log)

**Version:** 5.2.7, node 22.22.2.

## Repro

1. A parent process execs `node …/harper.js dev .`
2. Wait for health to come up.
3. `kill -9` the parent.

## Observed

The `harper.js` child stays alive, reparented to PID 1 (`ppid=1`), and is still running at 12s. `hdb.log` is unchanged after the kill — no output, **0 EPIPE lines**.

The good half first: the disk-fill loop from #2106 is verifiably gone on 5.2.7 — the `disableStdio` on EPIPE/EIO holds, and the orphan is quiet instead of writing ~29GB/hr. Thanks for that fix.

The residual: the process still **does not exit** when orphaned. It keeps running (and keeps holding its RocksDB lock and port) with no parent, indefinitely, with nothing in the log to say its parent is gone.

## Expected

An orphaned `harper.js dev` should notice parent death and shut down — e.g. watch for reparenting (poll `getppid() == 1`, or a parent-held pipe whose EOF triggers exit) and run the normal teardown. `dev` mode especially is by definition attached to something; outliving that something silently is how orphans accumulate.

## Why it bites

Supervisors and test harnesses that die abruptly (SIGKILL, OOM, crash) leave a live Harper holding the database lock and port. The next start then fails on the lock with no visible culprit — the orphan is quiet, so nothing points at it. Downstream we currently work around it with a preload that exits on reparent (tpsdev-ai/flair#1465), but the behavior belongs in the process itself.

Start at the harper.js dev entry point named in the reproduction and reproduce the parent SIGKILL scenario. Trace how the normal teardown is invoked and determine how parent loss can be detected without relying on log output; done means the orphan exits and releases its port and RocksDB lock.

Written by the indexing model from the issue text.