Fail fast and clean up when Playground bind port is occupied

## Problem

A `recipe-run` selected a loopback port already held by an existing SSH listener. Playground emitted `listen EADDRINUSE`, but the run remained blocked in `input.materialize` until the outer 20-minute timeout sent SIGTERM. The managed disposable MySQL container remained running and required operator cleanup.

## Evidence

- Bind error: `listen EADDRINUSE: address already in use 127.0.0.1:63055`.
- The pre-existing owner was an SSH listener with PPID 1, started roughly 14 hours before the recipe run.
- Artifact pointer remained at `lastCommand: input.materialize` and recorded interruption by SIGTERM only when the outer timeout expired.
- The managed `wp-codebox-mysql-*` container remained up after termination.

## Expected

1. Dynamic Playground port allocation excludes ports that cannot be bound, or retries allocation on `EADDRINUSE`.
2. Runtime startup/materialization propagates the bind failure immediately instead of hanging.
3. Managed runtime services are torn down on this terminal startup failure and SIGTERM path.

## Reproduction

1. Hold a local TCP listener on a candidate Playground bind port.
2. Force or stub dynamic allocation to return that occupied port.
3. Run a recipe with a managed service and an input mount requiring materialization.
4. Assert the run fails promptly with structured bind diagnostics and the managed service lifecycle reaches `released`/`teardown: completed`.

Discovered while validating #1821 against a real mounted WPCOM PHPUnit recipe.

Start by reproducing the occupied loopback-port case with a managed MySQL service, then trace dynamic port allocation, runtime startup/materialization, and the SIGTERM cleanup path. Done means prompt structured bind-failure reporting, no materialization hang, and the managed service reaching released/teardown: completed.

Written by the indexing model from the issue text.