Make sentinel messaging stack durable and self-healing across node restarts and eviction recovery

The current mcp-sentinel stack can get stuck after node pressure or control-plane disruption because Kafka and
Zookeeper do not have compatible persistence behavior.

Observed failure mode:

- node hit DiskPressure
- pods were evicted and recreated
- zookeeper came back with a new cluster identity
- kafka reused old PVC state and failed with InconsistentClusterIdException
- mcp-sentinel-ingest stayed unready because Kafka was unavailable
- recovery required manual PVC deletion, stale pod cleanup, and node restart

This should be fixed in platform code/manifests so recovery is automatic or at least deterministic.

Scope

- Make Kafka/Zookeeper storage strategy consistent
- either both persistent
- or both clearly disposable in dev mode
- Add an explicit dev-safe reset path for Kafka when Zookeeper identity changes
- Improve sentinel startup ordering/readiness so ingest/processor tolerate broker recovery better
- Reduce recovery churn after evictions by cleaning stale failed/completed pods during setup or health repair
flows
- Harden internal registry behavior during node pressure and image pull recovery
- Add documentation and an operator-visible repair command for this scenario

Acceptance criteria

- Reboot / eviction / temporary disk pressure does not leave Kafka permanently crashlooping
- mcp-sentinel-ingest recovers automatically once Kafka is healthy
- fresh setup or repair does not require manual PVC deletion for Kafka
- sentinel stack returns to healthy 1/1 state without manual pod cleanup
- add an automated test or documented reproducible recovery scenario