Shared grid validator: replace the two private Maidenhead regexes

[watson-ionis]

Two ingesters carry their own Maidenhead regex and they disagree. One of them is correct by accident.

• cmd/pskr-collector/main.go:81 — ^[A-R]{2}[0-9]{2}([a-x]{2})?$. Requires a lowercase subsquare and caps the locator at 6 characters. On a non-match it sets the field to "" (lines 208-213), so a rejection is indistinguishable from a station that sent nothing.
• cmd/contest-ingest/main.go:55 — ^[A-R]{2}[0-9]{2}([A-X]{2})?$. Requires an uppercase subsquare. It works only because line 330 calls strings.ToUpper() first. It also drops a failing header grid silently.

Measured impact of the PSKR pattern: 6,746,970,499 rows hold no usable grid pair. Valid input it discarded includes uppercase subsquares, 8- and 10-character locators, and lowercase fields. Collection began 2026-02-10 and the erasure ran the whole time.

What to build: one shared validator package, called by both ingesters and by the reference-tier editor. Per ADIF 3.1.7:

• GridSquare is 4, 6 or 8 characters; GridSquareExt carries the 2 or 4 beyond that; GridSquareList is comma-delimited.
• Validation is case-insensitive on input; normalise on store.
• Never drop, never blank. A failing locator is stored as received with a validity flag and a reason, so an audit can count failures by cause. This rule is what turns a regression into a visible metric instead of seven months of silent loss.
• Store at full precision; derive grid_4/grid_6 from the stored value rather than storing a truncated one.

Blank-on-invalid is the part that made this unrecoverable, so the flag/reason columns need a coordinated schema change alongside the validator.

Design: the ADIF-Anchored Dimensions record, "Future-proofing grids — one contract, both paths".

[watson-ionis]

Still live in production, measured 2026-09-26

The old regex is running right now. Two independent confirmations:

1. The data carries the regex's signature. Every grid that survived ingest today is one of exactly two shapes:

Surviving sender_grid	Rows today
4-char, plain	648,378
6-char, lowercase subsquare	2,486,169
6-char, uppercase subsquare	0
8-char or longer	0

Zero uppercase subsquares out of 3.1M is not a property of the source. It is a filter — and it is ^[A-R]{2}[0-9]{2}([a-x]{2})?$ exactly.

2. origin/main is unfixed. cmd/pskr-collector/main.go:82 still holds that pattern, and lines 209-214 still blank the field on a non-match. No branch carries a fix.

Current rate of loss

Date	Rows	Missing a grid pair	%
2026-09-23	35,750,700	25,448,482	94.20
2026-09-24	32,294,386	22,977,069	94.28
2026-09-25	28,549,019	20,499,426	94.26

Roughly 20-26 million spots a day are still losing a grid pair, and the ones with a grid are silently truncated to the two shapes above.

This raises the issue's priority above everything else queued against the reference tier: every day it stays unfixed adds another day of loss that the recovery table then has to cover. The date this fix goes live also becomes the recovery table's cutoff, so it is a dependency of that design too.

[watson-ionis]

Retraction: my "still live in production" comment above is wrong

Bob checked it and he is right. The collector is stopped and disabled — Judge ran disable --now after the #37 P7 sign-off. Verified myself:

• pskr.bronze max(timestamp) = 2026-09-26 14:34:30, with 0 rows after 15:00. The 3.1M "today" rows I measured were written before that cutover.
• pskr.capture_bronze, the faithful replacement, holds 7,058,162 spots with 0 blank locators, including 3,844,858 uppercase 6-character grids and 1,839,064 of 8 characters or more. Length distribution: 4 → 293,318 · 6 → 4,925,780 · 8 → 1,416,923 · 10 → 422,141.

All three classes the old regex erased are present in the capture. The fix is the cutover, not a regex patch — which is also why no branch "fixes" line 82, a fact I read as evidence of the opposite.

What I got wrong, mechanically: I queried pskr.bronze for "today", found the old regex's signature, and reported a running process. The signature was real but historical — it described rows written before 14:34:30. I never checked max(timestamp) or whether the unit was active, which is the one query that would have settled it. A fingerprint in stored data says what wrote those rows, not what is running now.

The "20–26 million a day" figure was true until 14:34 today and is zero after it.

What still stands in this issue

The shared validator is still worth building, for a different reason than urgency: origin/main does still carry the pattern at line 82, so the old collector remains re-enablable. Bob's queued PR removes the old collector and ingester from the RPM, which closes that properly. The validator then covers contest-ingest (still case-fragile at main:55) and the reference-tier editor, and gives the per-field null-rate check a single place to live.

Dropping the priority claim: this is no longer "outranks everything else."