E1004 / dual-controller panels: pin bb_epaper upstream, replace the fork shim with a runtime-gated bufferless module

[davelee98]

Why

esp32-s3-E1004 pinned a fork of bb_epaper (limengdu, PR bitbank2#32) for T133A01 support. That support has since landed upstream in 5dccfbb, so the fork pin can go.

Repinning on its own is not safe, and this is the important part: the E1004 code was guarded by #ifdef BBEP_T133A01 — a bb_epaper library define, not a firmware one. Upstream does not define it, so moving the pin compiled every E1004 path out of the binary while pio run -e esp32-s3-E1004 still reported SUCCESS. Firmware that cannot drive the panel, with no build error and no log line.

This PR repins, deletes the fork shim, and replaces it with a module that cannot fail that way.

What changed

Pin + env — all envs pin bitbank2/bb_epaper.git#5dccfbb. The [env] URL was previously unpinned, so CI and local builds each got whatever HEAD was at install time; locally that was c651b2a, while the source already carried a workaround for 71f6e70 (see epdAlignCustomPartialRamMode) — a commit not in the installed library. Pinning closes that divergence rather than creating one.

The esp32-s3-E1004 env is deleted. It was the same hardware as esp32-s3-N32R8-extuart, and the panel is selected at runtime by panel_ic_type. CI matrix 12 → 11.

New src/split_panel.{h,cpp} — gated at runtime on bbep.iFlags & BBEP_SPLIT_BUFFER, with static_asserts that turn a future library rename into a compile error on every target instead of a silent no-op.

Still bufferless. Upstream's own dual-CS writer (bbepWriteImage4bppDual, via bbepWritePlane) requires a 960 KB ucScreen; the data phase is driven from the library's own primitives instead — cs_mode = CMD_CS_NONE, manual chip-select, one DTM per controller, chunked bbepWriteData. That is the same idiom bbepWriteImage4bppDual uses internally; only the byte source differs. The other three phases need no help: the init sequence carries CMD_CS1/CMD_CS1_CS2 opcodes, and bbepRefresh/bbepSleep broadcast DRF/POFF off the SPLIT_BUFFER flag.

Keying on the flag rather than a panel id also covers EP81_SPECTRA_1024x576 (wire 0x2B), which previously took the generic path and drove only its left controller.

Bugs fixed rather than carried over

• Run length was computed in a uint16_t, so a chunk of ≥65536 bytes truncated to 0 and spun forever in a loop with no watchdog feed
• Truncated and overrun frames were dropped silently and still refreshed as success; splitPanelCloseFrame now returns a verdict and both refresh sites honour it
• No bound in the raw write path, and no busy gate before streaming
• waitforrefresh had an E1004 shortcut assuming bbepRefresh waited. True of the fork, false upstream — it could report success before BUSY even asserted and let the rail be cut mid-refresh
• No POFF after refresh: the C bbepRefresh issues DRF and returns; only the unused C++ BBEPAPER::refresh wrapper powers down
• cs_pin_2 was absent from configureDisplayPinsLowPower(), leaving the second chip select driven HIGH into an unpowered controller at rail cut

Also drops three branches that are now dead: the || splitPanelUsed() in both partial-update NACKs (bwgbry_split reports 4 bpp, so the bpp test already excludes them) and the forced REFRESH_FULL (the Spectra6 table rows carry a NULL pInitFast, so bbepRefresh falls back to pInitFull and both modes emit an identical sequence).

Also

• esp32-s3-N32R8-extuart-debug bench env, mirroring the N16R8 pair. Not in default_envs or firmware-targets.json, like the other -debug envs.
• CLAUDE.md env counts corrected (12 → 11, 11 → 10).

Cost

~1.6 KB flash per target, no RAM. All 11 CI targets build, plus all 16 local envs.

Hardware verification

Full image push cycle verified on an E1004. That exercises the parts that could not be settled by inspection:

• the dual-CS data phase and the crossing from CS1 to CS2 at the half-plane boundary
• the init sequence bbepRefresh re-sends after the data write. It contains no EPD_RESET and ends with PON + CCSET, so it acts as the pre-DRF preamble rather than a reset — confirmed not to disturb the streamed RAM. Worth noting the fork solved the same problem the opposite way, suppressing re-init, because its init table began with a reset; the two libraries are not interchangeable here by inspection.
• the refresh wait and POFF sequencing that replaced the stale waitforrefresh shortcut

Not verified: the 8.1" EP81_SPECTRA_1024x576 (wire 0x2B). It now takes this path off the BBEP_SPLIT_BUFFER flag rather than the generic single-CS path, where it drove only its left controller. That is a fix on paper, but it is an untested behaviour change and no such unit was available. A reviewer with one should exercise it before this merges, or say so and I will gate it back to the E1004 panel id only.