decode-drop/poisoned-cursor cluster tests: one runs in no CI path, both leak the restarted Harper child #716

Surfaced by @kriszyp's post-approval review on #691 (anchors failed, so the findings live in the review body). Companion to #715.

1. poisonedCopyCursorDataLoss.test.mjs runs in no CI path (verified)

The stress matrix (.github/workflows/stress-tests.yaml:136) includes integrationTests/cluster/decodeDropRecovery.test.mjs but not integrationTests/cluster/poisonedCopyCursorDataLoss.test.mjs. That suite is gated on HARPER_RUN_STRESS_TESTS=1, which normal cluster CI does not set — so the 279-line characterization test (and the production injection hook added for it) never executes anywhere. Add it to the stress matrix, or drop the stress gate if its runtime fits regular cluster CI.

2. Restart/teardown leak pattern in both cluster tests (per the review; confirm while fixing)

In decodeDropRecovery.test.mjs:120 (and the same pattern at poisonedCopyCursorDataLoss.test.mjs:158-194):

• deploy_component with restart: true responds before the old process exits, so the fixed sleep can race the outgoing process.
• The replacement Harper process is detached from the child handle the integration harness retains, so teardownHarper cannot stop it — the stress job can fail through the leaked-child backstop even when assertions pass.
• Cleanup calls teardownHarper(ctx.nodeA) instead of the required { harper: ctx.nodeA } shape.

Suggested fix per the review: deploy without the implicit restart, use restartNode() plus readiness checks, and call stopNodeProcess() before teardownHarper({ harper: node }).