Plan: cross-program alerts scoped by household assignments (#596)

GET /v1/eligibility/cross-program-alerts is removed (pre-1.0, no alias). Two new paths replace it:

Mixed deployments and rollback fail closed in ANY order: an old eligibility replica 404s the new paths (no service-bypass leak); a new replica 404s the old path for an old BFF. The worker is a typed path param — no Option<Uuid> query ambiguity. resolve_effective_worker(claims, path_worker) replaces enforce_worker_id_identity; a non-UUID claims.sub fails closed 403 (enrollment precedent). Both paths keep the Vec<CrossProgramAlert> feed shape and clamp(1,50) default 10 with the pagination-deviation justification comment (bounded top-N triage feed; rows have identity so ordering gains the id DESC tiebreak, but cursoring a 50-row feed is speculative machinery).

canopy-applications: GET /v1/workers/{worker_id}/assignments/household-ids — §B4 IDs-only projection, §B2 keyset page ordered by household_id (the active-only partial unique index is covering). Service-gated like its #408 siblings.

canopy-eligibility src/assignments.rs (lib crate): fetch_assigned_household_ids pages to exhaustion under one absolute 3s tokio::time::timeout (token mint + pages
decode — the BFF panel budget is 5s); hard cap MAX_ASSIGNED_HOUSEHOLDS = 5_000 (exceed ⇒ 502 assignment_set_too_large, never silent truncation); ALL failure arms ⇒ ApiError::BadGateway(fixed_client_safe_msg).with_code("applications_unreachable") (upstream bodies never echoed); a consecutive-failure breaker (5 → open 30s) so BFF retries cannot amplify an outage; empty set ⇒ [] without SQL. Metrics: lookup outcome/latency, assignment cardinality, scoped-query latency.

Bulk provenance failures persist quarantined verdicts with signature_verified = false; the alert queries filtered on status alone, so a REJECTED signed denial could surface as a panel alert. Both feed queries gain AND signature_verified (in-scope by plan approval — the same predicate + index this MR rebuilds).

New forward-only migration: replace idx_program_determinations_alert_status with (determined_at DESC, id DESC) WHERE status IN (six) AND signature_verified; add (household_id, determined_at DESC, id DESC) with the same predicate (the scoped-path index — without it a caseload with no recent alerts walks the whole jurisdiction alert history). Scoped SQL: per-household bounded LATERAL over unnest($2::uuid[]) (inner ORDER BY determined_at DESC, id DESC LIMIT $1 on the household index) → outer global top-N. A unit parity test pins both consts to the identical predicate (they are the index predicates). Revocation semantics: the assignments lookup is the authorization linearization point.

applications_url required beside persons_url, boot-validated (url::Url, http(s), no query/fragment, trailing slash normalized); value in config/canopy-eligibility/default.yaml; threaded as the ApplicationsBaseUrl newtype extension (bundle via FromRequestParts if the arg-count budget trips).

Both handlers publish one ids-only eligibility.cross_program_alerts.accessed event {actor, effective_worker, scope, assignment_count, result_count}; canopy-security’s wildcard subscriber ingests it. Per-household deny events deliberately NOT emitted (result-set scoping, not a per-household deny).

No unscoped-fallback flag exists (ratified). Activation is by provisioning order: provision real assignments BEFORE deploying (zero-assignment workers see an empty panel by design); runbook preflight query (% of alert-active households carrying an active assignment); monitor the new metrics + applications_unreachable rate. Deploy order is free; single-service rollback fails closed.

Program-level scoping (household assignment is intentionally a whole-household, cross-program grant — the #408 enrollment-gate model); keyset pagination of the feed; ReceiverContract (#1430); assignment events / read-model (rejected in spec); per-household audit events; the full-row assignments route’s ordering.