Ensure recipe-run timeout tears down child runtime processes

[chubes4]

Problem

A timed-out delegated WPCOM selected-page proof left wp-codebox recipe-run processes alive after the wrapper reported timeout.

Observed after edit-page timed out:

• Parent command had already reported runtime-blocked / timeout.
• A delegated wp-codebox recipe-run --recipe ...wordpress-com-ai-editable-landing.recipe.json --timeout 600s --json process was still running.
• The artifact pointer reported timeout at workflow.steps[0]:wordpress.run-php, but the runtime process remained alive.

Why this matters

Orphaned recipe/runtime processes make long-running proof loops unreliable and can consume local resources after the orchestrator has moved on.

Acceptance criteria

• When recipe-run hits its configured timeout, all child runtime/browser/Playground processes are terminated.
• If an external orchestrator kills recipe-run, child runtime processes are also cleaned up when possible.
• Timeout artifacts still include the active operation and available runtime diagnostics.
• Add a smoke test that fails before this fix by leaving a child process alive.