The wrapper gives up on a live stone lock after 10 s #126

Blocked by #124 (needs the heartbeat). #118 already made the wrapper's waits clock-based; this issue is about what it waits for.

Problem. The extension and the gemdb wrapper disagree on how long to wait for the stone lock. After #118 the extension holds the lock through the pre-start guards (copydbf -i, up to its 30 s timeout; 17 ms typical), startstone, up to 60 s of waiting for the stone to be ready, and startnetldi. Its waiters keep waiting while the holder pid is alive and progressing (ceiling about 2.5 min). The wrapper (the script generated in src/cli.ts) still gives up after 10 s, whether or not the holder is alive, and tells the user to remove a lock that is live.

Measured: a lock held by a live process for 30 s with no stone makes the wrapper print the "remove the lock" message at about 12 s, on both main and #118.

Not obvious: a fix needs a "holder is alive and making progress" signal that both sides understand. A pid check alone is not it (a reused pid looks alive). It is the nonce and mtime heartbeat from #124. Impact is small today: it needs a start slower than 10 s while a terminal runs gemdb.

Scope:

1. The wrapper waits while the holder is alive and the heartbeat is fresh, with the same ceiling as the extension.
2. When it does give up, the message says who holds the lock and for how long, and tells the user to remove it only if the holder is dead or stale.
3. One place for the wait constants, or a test that fails when the two sides differ.

Done when: a bash test holds the lock with a live, heartbeating process for 30 s with no stone, and the wrapper keeps waiting. With a dead or stale holder it steals or reports as the extension does.