docs: broaden hibernate() hardware confirmation to all 7 verified panels

Same WAIT_BUSY-timeout / reset-wake result held across every controller
family on hand (SSD16xx, UC8179, JD79676, HX8717), not just GDEQ0426T82 -
this is GxEPD2's general hibernate() contract, not a one-chip quirk.

CONTRIBUTING.md

@@ -194,14 +194,19 @@ 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.
+**Confirmed on hardware, all 7 panels currently marked `verified`**
+(GDEQ0426T82/SSD1677, GDEY075T7/UC8179, GDEY0213F52/JD79676, GDEH0154Z90/SSD1681,
+GDEQ0583T31/UC8179, GDEY0213Z98/SSD1680, GDEY0579F51/HX8717 - 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, on every one of the 7. 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. Same two-halves result across every controller family on
+hand (SSD16xx, UC8179, JD79676, HX8717) - this looks like GxEPD2's general
+`hibernate()` contract, not something specific to one chip.
 
 `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