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/theme.css

@@ -360,10 +360,9 @@ button.secondary:hover { background: var(--surface-alt); }
   color: var(--text);
   pointer-events: none;
 }
-.widget-box-remove {
+.widget-box-remove, .widget-box-settings {
   position: absolute;
   top: 4px;
-  right: 4px;
   width: 20px;
   height: 20px;
   padding: 0;
@@ -373,9 +372,12 @@ button.secondary:hover { background: var(--surface-alt); }
   border: none;
   background: var(--overlay);
   color: #fff;
+  font-size: 12px;
   cursor: pointer;
 }
-.widget-box-remove:hover { background: var(--overlay-hover); }
+.widget-box-remove { right: 4px; }
+.widget-box-settings { right: 28px; }
+.widget-box-remove:hover, .widget-box-settings:hover { background: var(--overlay-hover); }
 .widget-box-resize-handle {
   position: absolute;
   bottom: 0;
@@ -389,6 +391,32 @@ button.secondary:hover { background: var(--surface-alt); }
   border-bottom-right-radius: 4px;
 }
 
+#widget-dialog {
+  position: fixed;
+  margin: auto;
+  width: min(680px, calc(100vw - 32px));
+  max-height: min(720px, calc(100vh - 64px));
+  padding: 24px;
+  border: 1px solid var(--border);
+  border-radius: 14px;
+  background: var(--surface);
+  color: var(--text);
+  box-shadow: var(--shadow-hover);
+}
+#widget-dialog::backdrop { background: var(--overlay); }
+#widget-dialog-close {
+  position: absolute;
+  top: 14px;
+  right: 14px;
+  width: 30px;
+  height: 30px;
+  font-size: 18px;
+  z-index: 1;
+}
+.dialog-title { margin: 0 40px 16px 0; font-size: 18px; }
+#widget-dialog-body .card { box-shadow: none; }
+#widget-dialog-body .card:first-child { margin-top: 0; }
+
 code {
   background: var(--surface-alt);
   color: var(--text);