fix(picker): show multi-state border gauges in the gauge picker

[mousebrains]

Problem

The entire Columbia mainstem shows on the static gauges.html but is missing from gauge_picker.php (the "Build Your Own Gauges Page" picker).

Root cause: every Columbia mainstem gauge is a state-line border gauge whose gauge.state is the comma list OR,WA (John Day, The Dalles, Bonneville, Vancouver, St. Helens — all 5, all with live data). The picker filtered with an exact match:

WHERE g.state IN ('OR','WA')   -- never equals the literal 'OR,WA'

so the border gauges matched no state and were dropped — both server-side (the SQL) and client-side (gauge_picker.js partitioned AJAX rows with byState.get(r.state), an exact lookup that also misses "Oregon,Washington").

The static build never had this bug: web/build/gauges.py splits gauge.state on the comma so a border gauge renders under every one of its states (and filters.js splits data-state the same way). This PR brings the picker in line.

Fix

php/gauge_picker.php (3 spots) + static/gauge_picker.js (1 spot):

where	before	after
AJAX WHERE	g.state IN (?,?)	INSTR(',' || g.state || ',', ',OR,') > 0 OR-ed per abbrev — matches OR, OR,WA, WA,OR; not a substring of an unrelated code
AJAX row state	$ABBREV_TO_STATE['OR,WA'] → ''	split → "Oregon,Washington"
state pills	'OR,WA' → no pill	split → both Oregon and Washington pills (deduped)
gauge_picker.js	byState.get(r.state)	split r.state on comma, bucket under each requested state (buildAllRows() already dedupes by id)

No schema/data change — it's purely how the picker reads the existing state column.

Tests

tests/php/GaugePickerIntegrationTest.php gains an OR,WA seed gauge and asserts:

• it surfaces a Washington pill even with no single-state WA gauge seeded;
• it matches a Washington-only and an Oregon-only AJAX filter, returning state: "Oregon,Washington";
• a single-state MT gauge does not leak into a Washington filter (the comma-wrapped INSTR is anchored).

Local verification (full gate, green)

• phpunit GaugePickerIntegrationTest — 8/8 (4 new)
• full PHP suite — 523 tests, 2112 assertions, OK
• PHPStan level 9 + strict — no errors
• php-cs-fixer (dry-run) — clean
• biome — clean

🤖 Generated with Claude Code

[mousebrains]

Code Review — #96 fix(picker): show multi-state border gauges in the gauge picker

Verdict: ✅ Correct, well-tested, and faithful to the established pattern — ready to merge. CI is green; I also traced every path independently below. One out-of-scope sibling issue is worth a fast-follow (details at the end).

What it does

The 5 Columbia-mainstem gauges store gauge.state = 'OR,WA'. The picker filtered with g.state IN ('OR','WA'), which never equals the literal 'OR,WA', so all 5 border gauges silently dropped out of the picker (server SQL and the client's byState.get(r.state) exact lookup). This brings the picker in line with the static build, which already splits gauge.state on the comma.

Correctness — verified against the live DB and the surrounding code

• SQL match (INSTR(',' || g.state || ',', ',' || ? || ',') > 0) — correct and anchored: comma-wrapping both sides means WA matches OR,WA / WA,OR but not a substring of an unrelated code. Confirmed against the data: the live DB has exactly 5 OR,WA rows and zero state values containing whitespace, so the no-trim INSTR is safe. Placeholders stay positional and 1:1 with $abbrevs, the values are whitelisted via $STATE_TO_ABBREV, and the empty-$abbrevs early-return upstream prevents a degenerate WHERE (). The ($state_match) parens correctly isolate the OR-group from the trailing AND.
• Row re-join → 'Oregon,Washington' and pill split+dedupe — both mirror web/build/gauges.py:291‑296 exactly (split → map abbrev→name → re-join / keyed-set dedupe). The ?state=Washington deep-link now also pre-checks the right pill for a border gauge, which is a nice side win.
• gauge_picker.js bucketing — splitting r.state and pushing into each requested bucket is right; I confirmed buildAllRows() (lines 75‑87) dedupes by r.id via a Map, so a gauge landing in both Oregon and Washington buckets renders once.
• The comma data-state is harmless in the picker. I checked filters.js collectGroups() — it only builds a group per .filter-pills[data-group], and the picker's filter bar has only data-group="huc8" (no state group). So the rendered data-state="Oregon,Washington" is passive here; the splitCSV path is irrelevant to the picker. (On the static gauges.html the state group is rendered with split_csv=True at levels.py:469, so the PR's "filters.js splits data-state the same way" claim checks out there.)

Tests — good coverage

The 4 new cases hit the meaningful axes: WA pill surfaced from an OR,WA gauge with no single-state WA sibling; WA-only AJAX filter matches it and returns state: "Oregon,Washington"; OR filter returns both the single-state and border gauge; and the negative test that MT doesn't leak into a WA filter (guards the anchoring). The rowById() helper is mixed-safe, consistent with PHPStan level 9.

Sibling issue — recommend a fast-follow (not a blocker for this PR)

This PR makes border gauges selectable for the first time, and their destination — custom_gauges.php (?ids=…) — carries the same exact-match pattern this PR fixes in the picker:

• php/includes/custom_gauges_handler.php:218‑220 — isset(CUSTOM_GAUGES_STATE_ABBREVS['OR,WA']) is false → a border gauge contributes no state pill.
• :395 — CUSTOM_GAUGES_STATE_ABBREVS['OR,WA'] ?? '' → empty $state, so the :441 guard if ($state !== '' && $huc8 !== '') emits no data-state/data-huc8 at all → the row isn't a filterable row and silently ignores the state/watershed filters.
• :326 — the state group is hand-written <div class="filter-pills" data-group="state"> with no data-split="csv" (unlike the static build's levels.py:469).

Net effect there is milder than the picker bug (the gauge still renders with its flow/gage; it just escapes filtering and drops its pills), so it's fine to land this PR as-is. The complete fix is the same three-spot mirror of the static build: split at 218‑220 and 395, and add data-split="csv" at 326. Happy to do it as a follow-up.

Minor / nits

• The INSTR(...) predicate can't use an index on g.state, but gauge is tiny and the query is already gated by the latest_gauge_observation subquery — negligible.
• No schema/data change; purely how the picker reads the existing state column. 👍

🤖 Reviewed with Claude Code