Widget system Phase 4b: per-widget gear-icon config dialogs

Replaces the Photos/Calendar/Whiteboard tabs with a single Layout page
(now the frame's landing route) where each widget gets a gear icon
opening a dialog scoped to that specific widget's own settings. This
was the missing piece for genuinely independent same-type widgets --
"the Calendar tab" never made sense once a frame could hold more than
one calendar widget with different settings.

Data layer: FrameCalendar re-keyed from frame_id to widget_id, so each
calendar widget has its own independent included-calendars set. The
rekey runs as an unconditional post-startup step (like the existing
widget backfill), not a numbered migration -- it depends on calendar
widgets already existing, which themselves come from that same
backfill step, not from schema migration. Registering it as a numbered
migration would have run it first during a real upgrade, silently
dropping every row; caught by a new test that exercises the raw-SQL
upgrade path instead of the fresh-install create_all() shortcut every
other migration test takes.

API layer: every endpoint that used to assume "the frame's widget of
this type" (photo queue/thumbnail/preview, calendar select/color/
tasks/weather, whiteboard source/browse/preview) moved into
api_widgets.py under /api/frames/{id}/widgets/{widget_id}/..., with a
new require_widget_view/control dependency pair mirroring the existing
frame-level ones. Device status (battery/last-seen/firmware) got its
own frame-level /status endpoint, split out of the old photo-specific
/queue it used to piggyback on -- fixes the status bar going silently
blank on any frame without a photo widget.

UI layer: each widget type's existing settings markup/JS was ported
into a dialog partial + an explicit init/close function pair (the
content is now fetched and injected on demand, not loaded at page load
time). window.FRAME_API is repointed to the open dialog's widget-scoped
API base for its duration and restored on close; a separate
window.FRAME_BASE_API stays stable for the always-present header/
status-bar scripts.

Caught during manual browser testing: the consolidated config-save
endpoint initially expected a JSON body while the copied-over dialog JS
posts form-urlencoded data (the old convention) -- fixed to match, with
new HTTP-level test coverage that would have caught it immediately.

server/app/static/frame_layout.js

@@ -191,6 +191,15 @@ function renderCanvas() {
     label.textContent = WIDGET_LABELS[widget.widget_type] || widget.widget_type;
     box.appendChild(label);
 
+    const settingsBtn = document.createElement('button');
+    settingsBtn.type = 'button';
+    settingsBtn.className = 'widget-box-settings';
+    settingsBtn.textContent = '⚙';
+    settingsBtn.title = `${WIDGET_LABELS[widget.widget_type] || widget.widget_type} settings`;
+    settingsBtn.addEventListener('pointerdown', (e) => e.stopPropagation());
+    settingsBtn.addEventListener('click', (e) => { e.stopPropagation(); openWidgetDialog(widget); });
+    box.appendChild(settingsBtn);
+
     const removeBtn = document.createElement('button');
     removeBtn.type = 'button';
     removeBtn.className = 'widget-box-remove';
@@ -246,4 +255,66 @@ window.addEventListener('resize', () => {
   resizeTimer = setTimeout(layoutCanvas, 100);
 });
 
+// --- gear-icon dialog: each widget's own settings, fetched as an HTML
+// fragment (routers/frame_pages.py's widget_dialog) and injected into a
+// single shared <dialog>, rather than a separate page per widget type --
+// a frame can now have several widgets of the same type, so "the
+// Calendar tab" stopped meaning anything unambiguous.
+
+// widget_dialog_{photos,calendar,whiteboard}.js each define an
+// init<Type>Dialog()/close<Type>Dialog() pair (loaded unconditionally by
+// frame_layout.html, since which one runs depends on which widget's gear
+// icon was clicked).
+const DIALOG_INIT = { photos: initPhotosDialog, calendar: initCalendarDialog, whiteboard: initWhiteboardDialog };
+const DIALOG_CLOSE = { photos: closePhotosDialog, calendar: closeCalendarDialog, whiteboard: closeWhiteboardDialog };
+
+let openDialogWidgetType = null;
+
+async function openWidgetDialog(widget) {
+  const dialogEl = document.getElementById('widget-dialog');
+  const bodyEl = document.getElementById('widget-dialog-body');
+  bodyEl.innerHTML = '<p class="sub">Loading...</p>';
+  openDialogWidgetType = widget.widget_type;
+  dialogEl.showModal();
+  try {
+    const resp = await fetch(`/frames/${window.FRAME_ID}/widgets/${widget.id}/dialog`);
+    if (!resp.ok) throw new Error(await apiError(resp));
+    bodyEl.innerHTML = await resp.text();
+    // Every dialog script's fetch calls use window.FRAME_API as their
+    // base -- repointing it at this specific widget (instead of the
+    // frame-level window.FRAME_BASE_API) is what makes the SAME
+    // widget_dialog_photos.js/queue.js/etc. code work correctly no
+    // matter which widget's dialog is currently open. Restored on close.
+    window.FRAME_API = `${window.FRAME_BASE_API}/widgets/${widget.id}`;
+    const init = DIALOG_INIT[widget.widget_type];
+    if (init) init();
+  } catch (e) {
+    bodyEl.innerHTML = `<p class="sub">Could not load: ${e.message}</p>`;
+  }
+}
+
+document.getElementById('widget-dialog-close').addEventListener('click', () => {
+  document.getElementById('widget-dialog').close();
+});
+
+// Native <dialog> doesn't close on backdrop click by default -- a click
+// that lands outside the dialog's own box (but is still technically
+// "on" the dialog element, since the backdrop is part of it) counts as
+// a backdrop click.
+document.getElementById('widget-dialog').addEventListener('click', (e) => {
+  const dialogEl = e.currentTarget;
+  if (e.target !== dialogEl) return; // click landed on dialog content, not the backdrop
+  const rect = dialogEl.getBoundingClientRect();
+  const inside = e.clientX >= rect.left && e.clientX <= rect.right && e.clientY >= rect.top && e.clientY <= rect.bottom;
+  if (!inside) dialogEl.close();
+});
+
+document.getElementById('widget-dialog').addEventListener('close', () => {
+  const close = DIALOG_CLOSE[openDialogWidgetType];
+  if (close) close();
+  openDialogWidgetType = null;
+  window.FRAME_API = window.FRAME_BASE_API;
+  document.getElementById('widget-dialog-body').innerHTML = '';
+});
+
 loadWidgets();