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/calendar_render.py

@@ -63,8 +63,8 @@ def _event_colors(event: dict, owners_seen: list[str], palette_rgb: list | None)
     what tells the "same event, more than one calendar" case apart from
     an ordinary single-calendar event at render time -- see
     _draw_color_bar. Each source's own manually pinned color
-    (FrameCalendar.color_index -- see routers/api_frames.py's
-    api_calendar_color) resolves against whichever palette this frame
+    (FrameCalendar.color_index -- see routers/api_widgets.py's
+    api_widget_calendar_color) resolves against whichever palette this frame
     actually renders with, so a pinned "Blue" stays this frame's actual
     blue; a source with no color pinned falls back to the old
     auto-cycle-by-owner-name behavior. owners_seen is shared across every
@@ -644,7 +644,7 @@ def _build_week(events: list[dict], browse_offset: int, target_w: int, target_h:
                 weather_cities: list[dict] | None = None, weather_units: str = "fahrenheit",
                 days: int = 7, layout: str = "horizontal", tasks: list[dict] | None = None,
                 start_offset: int = 0) -> Image.Image:
-    """`days` (2-10, see routers/api_frames.py's clamp) side-by-side
+    """`days` (2-10, see routers/api_widgets.py's clamp) side-by-side
     columns (layout="horizontal", the original fixed-at-7 behavior
     generalized) or stacked bands (layout="vertical", reusing
     _draw_agenda_day the same way _build_today_tomorrow does, just for
@@ -657,7 +657,7 @@ def _build_week(events: list[dict], browse_offset: int, target_w: int, target_h:
     weekday, "start on the most recent Monday") exactly like before --
     otherwise "start of the week" doesn't mean much for an arbitrary day
     count, so it instead starts `start_offset` days from today (0 =
-    today, see routers/api_frames.py's api_config_save)."""
+    today, see routers/api_widgets.py's api_widget_config_save)."""
     img = Image.new("RGB", (target_w, target_h), BG)
     draw = ImageDraw.Draw(img)
     tier = _size_tier(target_w, target_h)