Correct busy-pin-polarity scope note: GxEPD2 already has this as data

Every vendor constructor passes its own busy_level literal - not something
we'd need datasheets to derive after all. Pinned as a later task to read it
off every driver in one pass rather than accreting incidentally.

components/gxepd2/busy_pin_polarity.md

@@ -1,12 +1,15 @@
 # Busy pin polarity, by panel
 
-Not a project scope item on its own - GxEPD2 doesn't record *why* a given
-panel/controller is active-high or active-low on BUSY, and pinning that
-down for every panel would mean reading every controller datasheet. This
-file just captures what we've read off each vendor driver constructor's
-`busy_level` argument to `GxEPD2_EPD(...)` as we happen to touch a panel
-for other reasons - `EpdPanelDescriptor::busy_active_level` in this
-component encodes the same fact per-panel (`true` = active-high).
+Started as "capture it when we happen upon it, not full project scope" on
+the assumption we'd need each controller's datasheet to explain *why* a
+panel is active-high/low on BUSY. Turns out GxEPD2 already has this as
+data, not something to derive: every vendor driver's constructor passes
+its own `busy_level` literal to `GxEPD2_EPD(cs, dc, rst, busy, busy_level,
+...)`, which is exactly what `EpdPanelDescriptor::busy_active_level`
+encodes per-panel here. So this **is** in scope to track for every panel,
+not just ones we happen to touch - just not yet: pinned as a later task to
+go read it off every vendor driver in one pass, rather than accreting it
+incidentally the way this table has so far.
 
 | Panel | Controller | busy_level (vendor ctor) | busy_active_level | Hardware-confirmed? |
 |---|---|---|---|---|