fix(server): "http-pull" panels are locked to PNG, whatever the photo knobs say

An ESPHome `online_image` picks its decoder at COMPILE time (`format: png`) and
sniffs the magic bytes, so a JPEG/WebP frame isn't merely lower quality to it --
it's undecodable ("Incorrect PNG signature") and the panel silently holds its
last frame.

That bit the M5Paper for real: its `photo_format` sat on "Auto", which inherits
the global JPEG default (deliberately JPEG for the ARMv6 photo Pi, which SIGILLs
on WebP), so every photo-frame push was undecodable and the panel looked frozen.

A retained per-device override fixes it today but is one HA select away from
silently breaking again, so gate it on the thing that actually implies the
constraint: `imageDelivery: "http-pull"`. The guard sits in pushController --
the chokepoint every render path funnels through -- and is scoped to the
delivery mechanism, so the mqtt-image Pi fleet still gets its ~10x smaller JPEG.

Tests cover both directions; the http-pull one fails without the guard.

Author: Sawtaytoes

packages/server/src/pushController.test.ts

@@ -11,14 +11,28 @@ const PNG = Buffer.from([
  * A push controller wired to the REAL device config store (the thing under
  * test) and thin fakes for everything else, recording what reached MQTT.
  */
-const makeController = () => {
+const makeController = ({
+  activeView = "Clock",
+  imageDelivery,
+  photoEncoding = { format: "png" },
+}: {
+  activeView?: string
+  imageDelivery?: "mqtt-image" | "http-pull"
+  photoEncoding?: { format: string; quality?: number }
+} = {}) => {
   const deviceConfigStore = createDeviceConfigStore()
   const publishedTopics: string[] = []
+  const renderedEncodings: unknown[] = []
+
+  const device = {
+    ...IMPRESSION_DEVICE,
+    ...(imageDelivery ? { imageDelivery } : {}),
+  }
 
   const pushController = createPushController({
-    devices: [IMPRESSION_DEVICE] as never,
+    devices: [device] as never,
     deviceStore: {
-      getActiveView: () => "Clock",
+      getActiveView: () => activeView,
       setActiveView: () => {},
     } as never,
     deviceConfigStore,
@@ -29,16 +43,22 @@ const makeController = () => {
       getAgenda: () => undefined,
     } as never,
     renderService: {
-      renderDevice: async () => PNG,
+      renderDevice: async ({
+        fullColourEncoding,
+      }: {
+        fullColourEncoding: unknown
+      }) => {
+        renderedEncodings.push(fullColourEncoding)
+        return PNG
+      },
     } as never,
     publisher: {
       publish: async ({ topic }: { topic: string }) => {
         publishedTopics.push(topic)
       },
     } as never,
     baseTopic: "castkit",
-    resolvePhotoEncoding: () =>
-      ({ format: "png" }) as never,
+    resolvePhotoEncoding: () => photoEncoding as never,
     resolveClockConfig: () =>
       ({
         timeZone: "America/Chicago",
@@ -55,9 +75,47 @@ const makeController = () => {
     pushController,
     deviceConfigStore,
     publishedTopics,
+    renderedEncodings,
   }
 }
 
+describe("pushDevice — 'http-pull' panels are locked to PNG", () => {
+  // An ESPHome `online_image` picks its decoder at COMPILE time, so a JPEG or
+  // WebP frame is not "lower quality" to it — it is undecodable ("Incorrect PNG
+  // signature") and the panel silently keeps its last frame. This bit the
+  // M5Paper for real: photo_format sat on "Auto", inherited the global JPEG
+  // default meant for the ARMv6 Pi, and the panel went blank.
+  test("a photo view still renders PNG despite a lossy photo encoding", async () => {
+    const { pushController, renderedEncodings } =
+      makeController({
+        activeView: "Photo Frame",
+        imageDelivery: "http-pull",
+        photoEncoding: { format: "jpeg", quality: 80 },
+      })
+
+    await pushController.pushDevice(IMPRESSION_DEVICE.id)
+
+    expect(renderedEncodings).toEqual([{ format: "png" }])
+  })
+
+  test("an mqtt-image panel on the same view still gets the lossy encoding", async () => {
+    // The guard must be scoped to the delivery mechanism — the Pi fleet decodes
+    // with PIL and genuinely wants the ~10x smaller JPEG.
+    const { pushController, renderedEncodings } =
+      makeController({
+        activeView: "Photo Frame",
+        imageDelivery: "mqtt-image",
+        photoEncoding: { format: "jpeg", quality: 80 },
+      })
+
+    await pushController.pushDevice(IMPRESSION_DEVICE.id)
+
+    expect(renderedEncodings).toEqual([
+      { format: "jpeg", quality: 80 },
+    ])
+  })
+})
+
 describe("pushDevice — the Updates pause switch", () => {
   test("publishes normally when updates were never configured", async () => {
     const { pushController, publishedTopics } =

packages/server/src/pushController.ts

@@ -136,10 +136,19 @@ export const createPushController = ({
     // Text views honour the mat's safe-area crop; photos bleed to the edge.
     const activeView = deviceStore.getActiveView(deviceId)
     const isBleedView = getIsBleedView(activeView)
+    // A "http-pull" panel is an ESPHome `online_image`, whose decoder is chosen
+    // at COMPILE time (`format: png`) — it sniffs the magic bytes and rejects
+    // anything else with "Incorrect PNG signature". So the photo-format knobs
+    // must not apply to it: leaving it on "Auto" made it inherit the global
+    // JPEG default (which exists for the ARMv6 photo Pi) and the panel went
+    // blank until someone noticed. Force PNG here rather than relying on a
+    // retained per-device override a future session could set back to "Auto".
+    const isFormatLockedToPng =
+      device.imageDelivery === "http-pull"
     // Only the bleed photo view may ship a lossy full-colour frame; every
     // other view stays lossless PNG (exact text + palette colours).
     const fullColourEncoding: FullColourEncoding =
-      isBleedView
+      isBleedView && !isFormatLockedToPng
         ? resolvePhotoEncoding(deviceId)
         : { format: "png" }
     const safeAreaInset = isBleedView