fix/tariff-cov

Partial zone resolution is silent — missing SIN zones produce no warning

packages/database/src/seed-tou-schedules.ts:111

A row is added to `skipped` only when `targets.length === 0`. If the tariff resolves fine but some of the 15 SIN zones are missing from the DB (pricing_zone rows not yet seeded), those zones are silently dropped: `pricingZoneId` returns null, the zone is excluded from `out`, and the parent row proceeds with the remaining zones. The final `upserted` count will be lower than expected with no warning — exactly the class of silent data gap this branch fixes. Fix: collect unresolved zone codes per row and emit a warning, e.g. `console.warn('partial: ${r.rate}/${r.region} missing zones: [DU, DV]')`.

Comment names BC system 'BCA' but map key and seed data use 'BC'

packages/database/src/seed-tou-schedules.ts:35

The JSDoc reads '…three (BCA, BCS, and the SIN…)' but the map key is `BC`. The official interconnected-system abbreviation is BCA; seed data uses `BC`. No code impact, but a future maintainer adding a new region could add `BCA` instead of `BC` and get zero matches. Change to '(BC, BCS, and the SIN…)' or add a parenthetical.

Stale comment row-count (~97 rows) no longer matches actual output (~699 DB rows after fan-out)

packages/database/src/seed-tou-schedules.ts:88

The pre-existing '97 rows over 9 rate×region combos' count correctly describes the CSV input but no longer the output. SIN's 43 rows × 15 zones = 645, plus 54 BC/BCS = 699 total upserts. An operator expecting ~97 might flag 699 as a bug. Update the comment to state the fan-out range.

'fourteen' vs 'fifteen' inconsistency in JSDoc comment

packages/database/src/seed-tou-schedules.ts:40

Line 36 says 'all fifteen non-Baja divisions' but line 40 says 'the other fourteen SIN zones'. Both are defensible (SIN has 15 zones total; 14 were missing before this fix), but read as contradictory at a glance. Suggest: 'left fourteen of the fifteen SIN zones with NO schedule at all.'

REGION_TO_ZONE_CODES constant has no test pinning its zone count or membership

packages/database/src/seed-tou-schedules.ts:45

The invariant that SIN maps to exactly 15 zone codes is not asserted anywhere. The original bug (SIN: 'DB' — one zone instead of 15) would have passed every existing test. A simple assertion on the constant's shape (`.length === 15`, or set-equality vs the authoritative DIVISION_TO_ZONE registry) would pin this against regression.

REGION_TO_ZONE_CODES not cross-checked against authoritative DIVISION_TO_ZONE registry

packages/database/src/seed-tou-schedules.ts:45

DIVISION_TO_ZONE in tariff-rate.scrape.ts lists all 17 CFE pricing zones. A test asserting that the union of all REGION_TO_ZONE_CODES arrays equals the set of all DIVISION_TO_ZONE values would catch any future zone added to CFE pricing that is not seeded into TOU schedules. config-integrity.test.ts already guards the scraper side — the seed side is the missing half.

Scraper fan-out is pinned in tests; seed fan-out is not — asymmetric coverage

services/utility/tariffs/cfe/__tests__/collector.test.ts:182

collector.test.ts pins the scraper's VALLE DE MEXICO → DL/DM/DN fan-out. The seed script's REGION_TO_ZONE_CODES fan-out is not pinned. Both feed the same downstream TOU classifier. The coverage is asymmetric given that the original bug was precisely in the seed path.

zoneCode returned in resolve type but never consumed at call site

packages/database/src/seed-tou-schedules.ts:96

`resolveTariffZones` returns `Array<{ tariffId, pricingZoneId, zoneCode }>`. The call site reads only `tz.tariffId` and `tz.pricingZoneId` for the insert — `zoneCode` is never used. If it was intended for partial-resolution logging (see correctness finding), wire it up. Otherwise drop the field from the return type.

699 serial DB round-trips where a batch insert would suffice

packages/database/src/seed-tou-schedules.ts:124

43 SIN rows × 15 zones + 54 BC/BCS rows = 699 sequential `await database.insert(...)` calls. Drizzle's `.insert().values([...])` accepts an array and `.onConflictDoUpdate` works on batch inserts too. Grouping inserts per CSV row (15 values per call) would reduce wall-clock time by ~14× on the SIN rows. For a one-off seed this is acceptable, but on a cloud Supabase at 10–15 ms/RTT it's a ~7–10 s run vs ~1 s batched.

generateULID called once per zone per row — this is correct behavior on conflict

packages/database/src/seed-tou-schedules.ts:128

On re-runs, the conflict target is (tariffId, pricingZoneId, startDate) so the generated publicId in the values() clause is discarded on conflict and the existing row's publicId is preserved (publicId is not in the onConflictDoUpdate set — correct). No action needed; noted so a batch-insert refactor doesn't accidentally share one ID across rows.