the hibernate job runs nightly and on dispatch, never on a push

The job is the slowest gate in the file and the only one whose fixture
has repeatedly gone red on a product that works: the plain cycle's
resume-then-reset, the Secure Boot half's poweroff that dies 180ms in,
and now 2026-08-31's suspend-then-hibernate cycle, which suspended, woke
on the alarm 16 seconds in, and then never hibernated while the guest
stayed up. A push gate that does that is one rerun away from being
ignored, and it was taxing every push with a 30 minute wait that only
mattered at release time.

So it moves to the daily heartbeat, which it already kept for
base-drift coverage, plus workflow_dispatch. The release flow gains one
explicit step, recorded in CONTRIBUTING: dispatch ci.yml on the exact
commit before tagging, because this job is the only automated check
that a hibernated machine comes back, and the nightly run alone cannot
pin that promise to a release.

What the job asserts is unchanged: boot_id across the cycle, the tmpfs
marker, uptime continuity, and doctor's honesty under Secure Boot
lockdown. What changes is when it is asked to prove it.

Author: Letdown2491

.github/workflows/ci.yml

@@ -45,7 +45,9 @@ jobs:
   # string. Changing the time in the `schedule:` block above would have
   # left all four matching nothing: both crons would run only the cheap
   # jobs, the daily boot heartbeat would stop, and the workflow would
-  # stay green, because a skipped job is a green job.
+  # stay green, because a skipped job is a green job. The hibernate job
+  # consumes this output too and deliberately gates differently, daily or
+  # dispatch and never a push; the reasons are in its own comment.
   #
   # A job rather than an `env:` value, because `env` is not available in
   # a job-level `if:` and actionlint says so. The cost is one runner
@@ -320,13 +322,25 @@ jobs:
   # this, kuma could tell exactly those machines that hibernate is ready
   # while logind refuses to do it. Asking both questions in one job is
   # cheap, because the expensive half is the install either way.
+  #
+  # It runs on the daily heartbeat and on a manual dispatch, and no longer
+  # on ordinary pushes. The fixture has accumulated documented QEMU
+  # artifact classes (a resume that resets instead of powering off, a
+  # second-firmware poweroff that dies 180ms in, and 2026-08-31's cycle
+  # that suspended, woke on the alarm, and then never hibernated with the
+  # guest alive), and a push gate that goes red for a fixture reason is
+  # one rerun away from being ignored. The nightly run keeps the coverage
+  # a moving Fedora demands, because resume is exactly what a base update
+  # breaks silently; the release flow dispatches this job on the exact
+  # commit before a tag, which CONTRIBUTING records. What it loses per
+  # push it keeps where the promise lives: this is the only automated
+  # check that a hibernated machine comes back.
   hibernate:
     runs-on: ubuntu-latest
     needs: when
     if: >-
-      github.event_name != 'pull_request' &&
-      !startsWith(github.ref, 'refs/tags/') &&
-      (github.event_name != 'schedule' || needs.when.outputs.daily == 'true')
+      github.event_name == 'workflow_dispatch' ||
+      (github.event_name == 'schedule' && needs.when.outputs.daily == 'true')
     # Longer than the install job it is built from, because it pays for
     # two boots and a hibernation on top of the same install.
     timeout-minutes: 120

CONTRIBUTING.md

@@ -83,7 +83,15 @@ previous release.
 The image stage is the one part that does not repeat on a tag. Cutting a
 release means tagging a commit that already went green on main, so the tag
 names a tree those images were already built from, and building them again
-only delays the release. Everything else in `ci.yml` still runs on the tag.
+only delays the release. Everything else in `ci.yml` still runs on the tag,
+with one exception: the hibernate job runs on the daily heartbeat and on a
+manual dispatch, never on a push. It is the slowest gate in the file, its
+fixture has accumulated documented QEMU artifact classes, and a push gate
+that goes red for a fixture reason is one rerun away from being ignored.
+So before tagging, dispatch `ci.yml` on the exact commit you intend to tag
+and wait for the hibernate job: it is the only automated check that a
+hibernated machine comes back, and a release is the thing claiming that
+promise.
 
 Two limits in that list worth knowing before you trust it. shellcheck reads
 `scripts/smoke.sh` and nothing else, so the shell that images actually run