docs: record hardware-confirmed power_off/hibernate behavior

Bench-tested on GDEQ0426T82/SSD1677 via the diag_update_no_reset() path:
hibernate() genuinely stops the panel acknowledging BUSY (WAIT_BUSY times
out, engine aborts), where power_off() does not - the panel responds fine
with no reset needed. A normal update() after hibernate() recovers
correctly, confirming RST-wake. Matches the predicted behavior exactly.

CONTRIBUTING.md

@@ -193,6 +193,16 @@ pattern distinct from what's on screen; if hibernate took, that pattern
 shouldn't render (and BUSY may behave oddly). A normal `update()` right after
 should then wake the panel and render correctly, confirming both the "off"
 and the "wakes via reset" halves and leaving the panel in a known state.
+
+**Confirmed on hardware** (GDEQ0426T82/SSD1677, 2026-10-19): `hibernate()` then
+`diag_update_no_reset()` doesn't just fail to render - it hits a genuine
+`WAIT_BUSY` timeout (`ABORTED`), i.e. the panel stops acknowledging BUSY at
+all while hibernating, not just ignoring the image. A subsequent normal
+`update()` (reset pulse included) recovered and rendered correctly. Separately,
+`power_off()` then `diag_update_no_reset()` rendered fine with no timeout and
+no reset needed, confirming `power_off()` really doesn't disable the panel the
+way `hibernate()` does.
+
 `power_off()` alone doesn't make the panel unresponsive (the next real
 refresh auto-powers back on), so this trick doesn't apply to it - its effect
 is only visible as reduced fading over long idle periods, or lower current