rstack dev: recover lost runs, one JSON error shape, kept logs #2639

Follow-up to #2635 and #2637. rstack dev reports enough to recover a broken run by hand, but four gaps remain in how it recovers and how it reports failures.

Recovery after a lost supervisor

When the supervisor is lost, stop and status list the run directory, the process groups and the exact database and role names, and the operator releases them by hand (see "When a run fails" in products/platform/PROJECT-DEV.md).

• Add rstack dev stop RUN_ID --recover that releases the listed resources itself.
• Guard against process ID reuse before signalling a recorded process group: confirm the group still belongs to the run (for example by start time or command line) and refuse otherwise.

One JSON error shape

--json failures use two shapes today:

• the helper prints registry.rstack.dev.v1 with status: "error", error (a string), optional run_id and recovery, and an undocumented cleanup_pending: true;
• the launcher prints registry.rstack.error.v1 with status: "refused" and error: {class, message} when the helper never starts.

A script has to handle both. Pick one envelope for every rstack dev failure, document cleanup_pending or drop it, and add a schema test for the result.

Kept logs

A failed start keeps its logs under <state>/failed/<run_id>/logs; a stopped or expired run removes them with the run directory. If the tails in error reports prove insufficient in practice, keep the logs of a stopped run for a bounded time.

PostgreSQL error codes from PostGIS provisioning

registry_breg::postgres::provision_postgis_prerequisites converts statement failures through From<tokio_postgres::Error>, which yields PostgresKernelError::Connection, so the SQLSTATE (for example 42501 when the administrator may not CREATE EXTENSION postgis) is lost. Keep the SQLSTATE, as other statement errors do. This code is shared with bregctl apply; rstack dev already adds a preflight and context for the common case.