### STEP 5 — THE CUT (poller observations, host UTC)
11:04:49.596Z poller armed, waiting for update_phase=pulling
11:04:50.561Z "updating":false 
11:04:52.501Z "updating":false 
11:04:54.436Z "updating":true "update_phase":"pulling"
11:04:54.439Z >>> CUTTING POWER: pct stop 9202
11:04:58.207Z >>> pct stop returned rc=0 ; status: status: stopped

NOTE: pct stop is not instantaneous — it returned 3.8 s after the decision, so the guest
      had up to ~3.8 s more of life inside the pulling phase. The phase at the moment of
      the decision is OBSERVED; the phase at the moment the kernel actually froze is INFERRED.

### POST-CRASH ON-DISK STATE, read from the STOPPED guest's rootfs (pct mount, no boot yet)
-- update-journal.json --
ABSENT

-- app.yaml as the crash left it --
# Auto-generated by felhom-controller — do not edit locked fields manually
deployed: true
deployed_at: "2026-09-21T10:57:12Z"
env:
    DOMAIN: enkisfelhom.hu
    SUBDOMAIN: status
locked_fields:
    - DOMAIN
    - SUBDOMAIN
desired_state: running
installed_images:
    uptime-kuma:
        ref: louislam/uptime-kuma:2.4.0
        digest: sha256:91e963bfda569ba115206e843febb446f473ab525add4e08b2b9e3beffa16985
        at: "2026-09-21T10:57:45Z"
pinned_images:
    uptime-kuma: louislam/uptime-kuma:2.5.0

-- live docker-compose.yml image line as the crash left it --
    image: louislam/uptime-kuma:2.5.0

-- pre-update compose copy, if one was saved --
total 32
drwxr-xr-x  2 100000 100000 4096 Sep 21 13:04 .
drwxr-xr-x 57 100000 100000 4096 Sep 13 22:22 ..
-rw-r--r--  1 100000 100000 3318 Sep 21 13:04 .felhom.yml
-rw-------  1 100000 100000  506 Sep 21 13:04 app.yaml
-rw-r--r--  1 100000 100000 1597 Sep 21 13:04 applied-compose.yml
-rw-r--r--  1 100000 100000 1597 Sep 21 13:04 docker-compose.yml
-rw-r--r--  1 100000 100000 1597 Sep 21 13:04 pre-update-applied.yml
-rw-r--r--  1 100000 100000 1597 Sep 21 13:04 pre-update-compose.yml
(unmounted)

### CORRECTION — the journal read above was WRONG.
    /var/lib/docker inside the guest is a separate MOUNT (not a symlink — my first wording was
    wrong too): mp0 mounts a 70G disk at /var/lib/felhom and its /docker subdirectory is bound
    onto /var/lib/docker (findmnt: /dev/loop1[/docker] /var/lib/docker ext4).
    'pct mount 9202' maps only the ROOTFS and does not apply the guest's internal mounts, so
    <rootfs>/var/lib/docker is an EMPTY MOUNTPOINT STUB from the host. 'test -f' therefore
    answered ABSENT for a file that exists — a FALSE NEGATIVE, not evidence.
    From the host the bytes are at <rootfs>/var/lib/felhom/docker/volumes/.../_data/data/.
    Found by running 'find' over the whole rootfs instead of trusting the one path.
    Path provenance and positive controls: 12-journal-path-provenance.txt.

### POST-CRASH update-journal.json, read from the STOPPED guest (correct path, still no boot)
-rw------- 1 100000 100000 439 Sep 21 13:04 /var/lib/lxc/9202/rootfs/var/lib/felhom/docker/volumes/felhom-controller-data/_data/data/update-journal.json
--- contents ---
{
  "updates": {
    "uptime-kuma": {
      "phase": "pulling",
      "started_at": "2026-09-21T11:04:52.924206274Z",
      "prev_pin": {
        "uptime-kuma": "louislam/uptime-kuma:2.4.0"
      },
      "prev_compose": "/opt/docker/stacks/uptime-kuma/pre-update-compose.yml",
      "prev_applied": "/opt/docker/stacks/uptime-kuma/pre-update-applied.yml",
      "proven_copy_at": "2026-09-21T11:01:46Z",
      "proven_tier": 1
    }
  }
}