#2867 Cancel, reject and supersede of a parent run should settle its suspended nested child runs

Follow-up to swamp-club#2736. With #2736 a parent run suspends while a nested child workflow waits on a manual_approval gate, and the child stays an ordinary suspended run. When the parent is cancelled, rejected or superseded, #2736 only lists the child runs it waited on (with cancel commands) and marks them as no longer awaited; it does not cancel them.

Design constraints found while planning #2736 (adversarial findings ADV-20, 43, 55, 69-73):

• Liveness must come from the run tracker row, never from the persisted status or run.pid: a run persisted suspended can still have sibling steps running, and releaseOwnership leaves a stale pid.
• workflow.reject is dispatched inside withSyncGate (connection.ts), so aborting and awaiting a registered child there deadlocks on the child's final push. Reject also saves the parent failed before anything else could run.
• Cancel has several entry points: WebSocket workflow.cancel, HTTP /api/v1/cancel/workflow-run/:id and the bulk cancel (cancelExecution in serve.ts), the CLI cancelLocalRun including --all, reject, and supersede. The cascade needs one ungated serve helper: abort and await registered children outside the gate, reserve each suspended child around its read, cancel and save, then settle the parent.
• A running child inside a serve-driven parent is not registered under its own id, so a cancel must map it to the root registration.
• Recover, retry and --from sweeps must treat interrupted children as superseded, not blocking.
• Stale children from a parent that crashed before saving its wait can only be found by back-link, which needs a findRunsByParent repository port over the per-workflow indexes.