[Ticket]: Spike - root-cause the stack-wide container exit 137

### Type
Spike / Investigation

### Summary
Investigate why the entire local Compose stack exited with code 137 simultaneously on 2026-08-25.

### Intent
So local development is not interrupted by an unexplained whole-stack kill.

### Source of truth (links)
- Observed 2026-08-25; volumes survived, so it was not `down -v`

### Current Behavior
Every container exited 137 at once. Cause unidentified. Data volumes were intact afterwards.

### Expected Behavior
Either a root cause with a fix, or a documented benign explanation.

### Acceptance Criteria
- [ ] Docker daemon and host memory logs examined for the window
- [ ] Determined whether this was OOM, a daemon restart, or an external signal
- [ ] Finding written into the troubleshooting guide either way
- [ ] Time-boxed to one day; report findings even if inconclusive

### Out of Scope
Reducing the stack's memory footprint, unless the spike shows OOM is the cause.

### Technical Context
137 = SIGKILL. Simultaneity across all containers points at the daemon or the host, not any single service. Note that this workspace already documents host memory pressure during `--all-targets` builds.

### Risks
May be unreproducible. Say so plainly rather than inventing a cause - an unfalsifiable explanation is worse than an open question.

### Test Plan
Review host logs for the window; attempt reproduction under memory pressure with a concurrent cargo build.

### Verification evidence
- [ ] Test added and proven to fail before the change
- [ ] `just all-checks` green
- [ ] Every new or changed `src` file is <= 200 LoC

### Human accountable owner
@stephane-segning

### AI Usage Declaration
Ticket drafted with AI assistance from a verified repo audit.
Structure and estimates drafted with AI from a verified repository audit (file
line counts, config keys, and dependency state were read from the actual tree,
not assumed). A human owns intent, scope, and the release commitment.

### Human verification completed
- [ ] I can explain this work without referring to the AI-generated text
- [ ] Acceptance criteria are testable
- [ ] Source of truth is a real link, not boilerplate

Governance: https://adorsys-gis.github.io/ai-governance/

Start by reviewing Docker daemon and host memory logs for the 2026-08-25 window, then attempt the described memory-pressure scenario with a concurrent cargo build. Compare the evidence for OOM, daemon restart, or external signal, and document the finding—or an explicitly inconclusive result—in the troubleshooting guide; run just all-checks afterward.

Written by the indexing model from the issue text.