recipe-run exits without a parseable summary on RuntimeServiceProvisionError; consumers report zero tests instead of the cause

[chubes4]

Summary

When a managed runtime service fails to provision (Docker ENOENT, or external provider with unresolved secret_env), recipe-run exits without flushing its JSON summary. Every downstream consumer (Homeboy's wp-codebox-phpunit-adapter.mjs) then classifies the run as recipe_run_payload_unparseable and reports zero executed tests, hiding the real cause. Homeboy has six open issues that are all this symptom (Extra-Chill/homeboy #12683 #12776 #12784 #12795 #13132 #13136, now consolidated under #14449) and this repo has #2327 ("intermittently returns unparseable payload").

Evidence

From Extra-Chill/data-machine-events#795 (Docker-free host, before the provider switch):

RuntimeServiceProvisionError: Managed runtime service failed: wordpress-database
  provider: 'docker', diagnostic: { code: 'provider-unavailable', command: 'docker', cause: { code: 'ENOENT' } }

Consumer side (Homeboy adapter, wordpress/scripts/test/wp-codebox-phpunit-adapter.mjs:1473):

PHPUNIT_ZERO_TESTS cause=recipe_run_payload_unparseable
  The recipe-run JSON payload could not be parsed, so no execution step ledger is available.
  Read logs/recipe-run.stdout.log and logs/recipe-run.stderr.log for the raw recipe-run output; a crashed or truncated recipe-run may not have flushed its JSON summary.

Same result today on the same host with provider: external and WP_CODEBOX_DB_* unset.

Expected

recipe-run always emits a parseable summary, including on early failure. On RuntimeServiceProvisionError (and any pre-execution fatal), the payload should carry parse_status-compatible structure with an empty executions ledger plus a structured failure block: { phase: "runtime_services", service: "wordpress-database", provider, diagnostic: { code, command?, cause? } }. Exit code non-zero as today.

Where: packages/cli/src/runtime-services.ts raises RuntimeServiceProvisionError; the recipe-run summary writer needs a try/finally (or top-level catch) that serializes the error into the summary before exit. Add a test alongside tests/runtime-services.test.ts asserting the summary is written and parseable when provisioning throws.

Refs #2327.

[chubes4]

Consumer-side mitigation has landed in Extra-Chill/homeboy-extensions#2819: the adapter now reads the already-written runtime-service evidence and reports runtime_service_provider_unavailable instead of recipe_run_payload_unparseable. That removes the urgency here, but the upstream ask stands — recipe-run should still flush a parseable summary with a structured failure block on RuntimeServiceProvisionError so consumers that don't read the evidence sidecar (and older adapter pins) aren't left with wreckage. Lowering priority, not withdrawing.