Update to support upstream weatherfeeder v0.12.1 and add ends field to the alerts schema

docs/api.md

@@ -212,14 +212,17 @@ Run `data` fields:
 | `alerts` | array | active alerts, possibly empty |
 
 Alerts are active when `messageType` is not `Cancel`, `effective` is absent or
-at or before request time, and `expires` is absent or after request time.
+at or before request time, and the alert end boundary is absent or after request
+time. The end boundary prefers `ends`; if `ends` is absent, `expires` is used as
+a fallback for older rows or providers that do not supply an alert-period end.
 `onset` is presented when available but is not used as the active boundary.
 
 Alert fields include `id`, `event`, `headline`, `severity`, `urgency`,
 `certainty`, `status`, `messageType`, `category`, `response`, `description`,
-`instruction`, `sent`, `effective`, `onset`, `expires`, `areaDescription`,
-`senderName`, and `references`. Most alert fields are optional except `id` when
-an alert item is present.
+`instruction`, `sent`, `effective`, `onset`, `ends`, `expires`,
+`areaDescription`, `senderName`, and `references`. Most alert fields are
+optional except `id` when an alert item is present. `ends` is the alert-period
+end; `expires` is provider expiration metadata.
 
 Reference fields are `id`, `identifier`, `sender`, and `sent`.
 

docs/integrations/weatherfeeder-postgres.md

@@ -105,8 +105,8 @@ and `event_emitted_at`.
 
 `alert_index`, `alert_id`, `event`, `headline`, `severity`, `urgency`,
 `certainty`, `status`, `message_type`, `category`, `response`, `description`,
-`instruction`, `sent`, `effective`, `onset`, `expires`, `area_description`,
-`sender_name`, and `run_event_id`.
+`instruction`, `sent`, `effective`, `onset`, `ends`, `expires`,
+`area_description`, `sender_name`, and `run_event_id`.
 
 ### `alert_references`
 

docs/internal/http-adapter.md

@@ -134,7 +134,9 @@ behavior deterministic.
 
 `/alerts/active` uses the shared `format` and `units` binder. The handler calls
 the application service with `alertNow().UTC()` so active alert filtering uses
-the request-time instant while remaining deterministic in endpoint tests.
+the request-time instant while remaining deterministic in endpoint tests. The
+application service prefers alert `ends` over `expires` when deciding whether an
+alert has ended.
 
 ## Outlook Filters
 

docs/internal/postgres-repository.md

@@ -79,8 +79,9 @@ successful responses with `data: null`.
 - `CurrentConditions`: aggregates recent rows from `observations` using the
   application-provided observation window.
 - `LatestAlertRun`: latest row from `alert_runs`, then child `alerts` and
-  `alert_references`. This is the latest stored alert snapshot; active-time
-  filtering is performed by the application service.
+  `alert_references`. This is the latest stored alert snapshot. The repository
+  maps both `ends` and `expires`; active-time filtering is performed by the
+  application service.
 - `LatestHourlyForecast`: latest `forecasts` row where `product = 'hourly'`,
   then child `forecast_periods`.
 - `LatestNarrativeForecast`: latest `forecasts` row where