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

## 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.