settings: whole-array writes have no version guard — lost updates on concurrent edits (Tts:Pronunciations et al.)

[genwave-radio]

Surfaced at T144's review (probe: DELETE ∥ PUT both 2xx, the edit silently vanished — whichever whole-array revision writes last wins). StationSettingsStore.WriteAsync is a blind upsert; every JSON-array settings key (Tts:Pronunciations, Tts:Corrections, …) carries the posture. Content addressing (T144) means a concurrent write can only LOSE a revision, never mutate the wrong rule — ruled acceptable for the single-operator surface. The fuller fix is the house MediaController.Patch precedent: If-Match over an ETag of the serialized array → 428 absent / 409 mismatch. Project #9.

[genwave-radio]

📐 Session scouting note (2026-08-13 bug pass): the stated fix shape doesn't map cleanly onto the write path — needs a shape ruling before building.

The ticket prescribes the MediaController.Patch precedent (If-Match over an ETag of the serialized array → 428 absent / 409 mismatch). Two frictions found on inspection:

1. SettingsController is a batch endpoint — one request persists N keys via store.WriteAsync(update.Key, …) in a loop (SettingsController.cs:156-180). A single If-Match header can't carry per-key versions, so the precedent doesn't transplant as-is. The natural adaptation is a per-update expected-version field in SettingUpdateRequest (409 lists the stale keys), which deviates from the pure header shape.
2. Lockstep UI change required — 428-when-absent breaks every existing admin-ui settings save until the UI threads ETags through (reads must start returning them too). So the PR is backend + frontend + both spec suites in one slice.

Options for the ruling:

• (a) per-update expectedVersion in the batch body (header-free, batch-honest; 428 when a guarded array key arrives without one);
• (b) carve array-key writes out of the batch endpoint into per-key PUTs that take real If-Match (closest to the precedent, more API surface);
• (c) keep the documented accepted posture (content addressing means a lost revision, never a mutated one) and close as wontfix-for-now.

Not building unilaterally since (a)/(b) change API shape. One more data point for sizing: Tts:Pronunciations also has the dedicated PronunciationsController CRUD path, which would need the same guard to make the posture consistent.