[Bubblewrap] Proxy-only egress: slirp4netns dying mid-run leaves the sandbox with a broken network and no error

### Relevant area(s)

Linux (Bubblewrap backend)

### Brief description of your issue

Bubblewrap proxy-only networking (schema 0.8+) runs `slirp4netns` as the sandbox's only connectivity provider, supervised by a helper process that also installs the egress rules. Teardown was hardened in #931 — `stop()` logs slirp's exit status and a bounded stderr tail — but **nothing observes slirp for the lifetime of the workload**.

If `slirp4netns` (or the supervisor) dies *after* readiness is signalled and *before* the workload finishes, the sandbox keeps running with a network that silently stops working. Every outbound connection fails with a generic transport error, the run is attributed to whatever the workload reported, and the actual cause is only visible in the supervisor's stderr after the fact.

There is a related, narrower race: slirp can die between the readiness poll succeeding and the gate being released, so a sandbox can start against a connectivity provider that is already gone.

Note this is a **diagnosability and reliability** problem, not a containment bypass: a dead slirp removes connectivity rather than granting it, and the egress rules live in the sandbox's own network namespace, so they stay in force.

Source: adversarial review of #931 (High, reliability axis). Deferred from that PR because the fix needs a real design (a monitor with a defined ownership and teardown story), not a local change.

### Steps to reproduce

1. Run a Bubblewrap sandbox with schema `0.8.0-alpha` and `network.proxy` configured, using a long-running workload (e.g. a loop issuing an HTTPS request every second through the proxy).
2. From the host, identify the `slirp4netns` process for that sandbox and `kill -9` it.
3. Observe the workload's subsequent requests.

### Expected behavior

Loss of the connectivity provider should be detected while the workload is running. The sandbox should be terminated (or the failure surfaced) with an error that names slirp's exit status and stderr, so the caller can distinguish "the network provider died" from "the workload's requests failed".

Additionally, slirp's liveness should be rechecked immediately before the startup gate is released, closing the window between the readiness poll and the workload starting.

### Actual behavior

Nothing monitors slirp or the supervisor during the run. The workload continues with a broken network and receives only generic connection errors; the real cause is available solely in the supervisor's stderr, and only once teardown runs.