recipe-run preview hold should support failed or in-progress workflows for debugging

[chubes4]

Problem

wp-codebox recipe-run --preview-hold --preview-hold-blocking is useful for opening a live Playground preview. Today the preview is effectively tied to successful recipe completion: if a workflow step fails or a long proof never reaches the terminal hold phase, the runtime is torn down and callers cannot inspect the live page/editor that failed.

For generic browser/runtime workflows, callers need a way to hold the preview when a workflow fails or while a long workflow is blocked, without pretending the proof succeeded.

Evidence

While proving a WPCOM selected-page edit/save/export workflow, WP Codebox could emit a local/public preview URL after the early browser proof, but subsequent workflow failure caused the runtime to be destroyed before a human could inspect the editor state. This is a generic lifecycle problem: preview hold should be a debugging/inspection mode, not a success-only artifact.

Desired behavior

Add a generic preview-hold failure policy, for example:

• --preview-hold-on-failure
• or --preview-hold-policy=success|failure|always

The runtime should remain held for the configured hold period or blocking session even if a workflow step fails, while preserving the run status as failed.

Acceptance criteria

• A failed recipe can still emit preview.localUrl/preview.publicUrl when preview hold-on-failure is requested.
• Run status remains failed; holding a preview must not mask proof failure.
• Artifacts record failure status and preview lifecycle separately.
• Existing success-only behavior remains the default unless the new option is supplied.
• No WPCOM-specific logic or fixtures.