Add server-side support for a second panel (13.3in Spectra 6 / EE02) and scaffold its firmware target

Server: Frame.panel_type (new column + migration) is auto-derived from
the device's reported board (X-Frame-Board), never user-set -- the
panel is a property of the hardware, not a picker in the UI.
image_pipeline's packing/render pipeline is parameterized by panel
geometry instead of hardcoded 800x480 globals, with the real confirmed
13.3in geometry (1600x1200) registered alongside the original 7.3in
panel. Existing 7.3in frames are unaffected (column default + board
mapping both resolve to the original panel).

Board identifiers are also renamed (devkit/xiao -> devkit_esp32c6/
xiao_esp32c6, plus new "ee02") since the EE02 board also carries a XIAO
module -- "xiao" alone stopped disambiguating hardware. The server
keeps accepting the legacy bare names indefinitely for already-flashed
devices.

Firmware: scaffolds a third build target (ee02, ESP32-S3 -- a real
chip-target change, not just a same-chip Kconfig variant like xiao) and
a new epd13in3e driver component skeleton. The actual panel init/LUT/
refresh register sequence isn't ported from vendor demo code yet (none
was available), so that component deliberately fails to compile
(#error) rather than risk sending unverified register values to real
hardware -- devkit/xiao are unaffected and build identically to before.
CI's ee02 build step is continue-on-error for the same reason.

.gitea/workflows/firmware-build-check.yml

@@ -3,9 +3,11 @@ name: Firmware build check
 # Fires on every push touching firmware source, unlike
 # firmware-release-build.yml (which only builds+publishes when
 # firmware/version.txt itself is bumped -- the "cut a release" signal).
-# This just verifies both board variants still compile; nothing else in
-# CI catches a firmware/** push that breaks the build until someone
-# happens to bump the version next.
+# This just verifies every board variant still compiles (or, for ee02,
+# that everything up to its known/tracked #error still compiles --
+# see that step's own comment); nothing else in CI catches a
+# firmware/** push that breaks the build until someone happens to bump
+# the version next.
 on:
   push:
     branches: [main]
@@ -49,3 +51,26 @@ jobs:
           docker cp "$PWD/." "$cid:/workspace"
           docker start -a "$cid"
           docker rm "$cid"
+
+      # Expected to fail until firmware/components/epd13in3e's panel
+      # driver is ported from vendor demo code (deliberate #error, see
+      # that file's own top comment) -- continue-on-error so this known
+      # gap doesn't block every other firmware/** push. Still worth
+      # running: catches a regression in the surrounding scaffolding
+      # (Kconfig, main/CMakeLists.txt's component selection, sdkconfig
+      # layering) up to the point of that #error, same value a build
+      # check normally provides. Remove continue-on-error once
+      # epd13in3e's driver is real, so a build failure here goes back to
+      # being a genuine regression signal.
+      - name: Build (ee02 -- Seeed EE02, XIAO ESP32-S3 Plus + 13.3in panel)
+        continue-on-error: true
+        run: |
+          cid=$(docker create -w /workspace/firmware espressif/idf:release-v6.0 bash -c '
+            git config --global --add safe.directory /workspace &&
+            . "$IDF_PATH/export.sh" &&
+            ./build_for_board.sh ee02 set-target esp32s3 &&
+            ./build_for_board.sh ee02 build
+          ')
+          docker cp "$PWD/." "$cid:/workspace"
+          docker start -a "$cid"
+          docker rm "$cid"