Scaffold weather app: reception forecast display + shared internal API

- Backend: Fastify service polling Met Office DataHub (Global Spot: hourly,
  three-hourly, daily endpoints) with Open-Meteo fallback, hourly refresh.
  Reuses settings' hotel_location/met_office integrations (same pattern as
  hvac's lib/weather.js) rather than its own credential copy.
- Three display tiers stored in one forecast_points table: today (hourly),
  next 2 days (3-hourly), days 4-7 (plain daily) - 7 days total.
- Public /api/public/forecast (no auth) feeds the reception kiosk display;
  /api/internal/forecast (WEATHER_SECRET bearer) lets other apps read the
  stored forecast instead of polling providers themselves; /api/admin/*
  (normal JWT + settings cap) is the staff status/refresh page.
- Frontend: root / is the public full-screen Display (no AuthGate at all -
  first genuinely public app in the stack); /admin is the authed status
  page. apps.base_path is /weather/admin so the portal card opens the
  admin view directly, precedented by forecasting's history sub-route.
- LXC 131 / 10.10.10.131, registered in auth/src/db.js, push-to-forgejo.sh,
  and stack-init/install-stack.sh (deploy_weather + --only dispatch + full
  install chain).
- Typechecks and builds clean; not yet deployed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

backend/src/db.js

@@ -0,0 +1,54 @@
+import pg from 'pg'
+
+const { Pool } = pg
+export const pool = new Pool({ connectionString: process.env.DATABASE_URL })
+
+export async function initDb() {
+  await pool.query(`
+    -- App-wide key/value status (last fetch time/provider/error) — same KV pattern as
+    -- tasks' config table, just used for status rather than user-facing settings since
+    -- the real settings (hotel_location, met_office key) live centrally in the
+    -- shared 'settings' app, not here.
+    CREATE TABLE IF NOT EXISTS status (
+      key        TEXT PRIMARY KEY,
+      value      JSONB NOT NULL,
+      updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
+    );
+
+    -- One row per forecast data point. 'resolution' is which display tier it belongs
+    -- to: 'hourly' (today, full day), '3hourly' (next 2 days), 'daily' (days 4-7).
+    -- temp_min_c only populated for 'daily' rows (hourly/3hourly are point-in-time).
+    -- Each refresh cycle replaces the full set for a resolution in one transaction
+    -- (see lib/weather-fetch.js) rather than patching individual rows, so stale points
+    -- from a provider that later drops out of range never linger.
+    CREATE TABLE IF NOT EXISTS forecast_points (
+      id             SERIAL PRIMARY KEY,
+      resolution     TEXT NOT NULL,
+      ts             TIMESTAMPTZ NOT NULL,
+      temp_c         NUMERIC NOT NULL,
+      temp_min_c     NUMERIC,
+      feels_like_c   NUMERIC,
+      precip_prob    NUMERIC,
+      wind_speed_mph NUMERIC,
+      icon           TEXT NOT NULL,
+      condition_text TEXT,
+      source         TEXT NOT NULL,
+      fetched_at     TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+      UNIQUE (resolution, ts)
+    );
+    CREATE INDEX IF NOT EXISTS forecast_points_res_ts_idx ON forecast_points (resolution, ts);
+  `)
+}
+
+export async function getStatus() {
+  const { rows } = await pool.query('SELECT key, value FROM status')
+  return Object.fromEntries(rows.map(r => [r.key, r.value]))
+}
+
+export async function setStatus(key, value) {
+  await pool.query(
+    `INSERT INTO status (key, value, updated_at) VALUES ($1, $2, NOW())
+     ON CONFLICT (key) DO UPDATE SET value = EXCLUDED.value, updated_at = NOW()`,
+    [key, JSON.stringify(value)]
+  )
+}