fix(store): sync simulator with activeBoardId in addBoard

When addBoard promotes a board to active (first board, or the previously
active one was removed) it set activeBoardId without syncing s.simulator,
unlike setActiveBoardId which sets both. Parts that read s.simulator - SPI
displays (ILI9341) attach spi.onByte to the active simulator - then wired
onto the previous board's bus and never received data, so a boards[] ESP32
example with a TFT rendered black. Sync simulator to the promoted board
(no-op when the active board is unchanged).

frontend/src/store/useSimulatorStore.ts

@@ -1248,7 +1248,19 @@ export const useSimulatorStore = create<SimulatorState>((set, get) => {
         // through the picker; this just closes the API gap.
         const stillExists = s.boards.some((b) => b.id === s.activeBoardId);
         const nextActive = stillExists ? s.activeBoardId : id;
-        return { boards: [...s.boards, newBoard], activeBoardId: nextActive };
+        // Keep `simulator` in sync with `activeBoardId`. setActiveBoardId is the
+        // only other place that promotes a board, and it sets BOTH — if addBoard
+        // promotes a board (first board, or the active one was removed) without
+        // syncing the simulator, s.simulator stays pointed at the previous board.
+        // Parts that read s.simulator (SPI displays like ILI9341, which attach
+        // `spi.onByte` to the active simulator) then wire onto the wrong board's
+        // bus and never receive data — the "boards[] ESP32 TFT renders black"
+        // bug. When nextActive is unchanged this is a no-op (same reference).
+        return {
+          boards: [...s.boards, newBoard],
+          activeBoardId: nextActive,
+          simulator: simulatorMap.get(nextActive) ?? s.simulator,
+        };
       });
       // Create the editor file group for this board
       useEditorStore.getState().createFileGroup(`group-${id}`);