fix(confirmations): count a LoTW "V" everywhere, not only in the awards

An operator's screenshot had it side by side: the Awards panel showed Morocco
validated on five bands, and the band/mode matrix two inches above showed the
entity as merely worked.

ADIF's QSL_Rcvd enumeration has both Y and V — "received" and "verified" — and
V is what a LoTW download writes for a confirmation the ARRL has validated. The
award engine's isYes accepted "Y" or "V". Everything else in the app compared
against 'Y' alone: the worked-before status grid, the slot statistics, the row
colouring by QSL status, the awards QSO list, the call history badges. So the
confirmations an operator cares most about were the ones that did not count.

Now one definition per side, named so the next reader finds the other:
qso.ConfirmedValues on the Go side, used by the queries themselves, and
isQSLConfirmed in lib/qsl on the frontend, which rowColors and the panels call
instead of testing the letter.

The Go test drives the real query shape against a real database with a 'V' row
— the constant being right is not the point, the queries using it is.

frontend/src/lib/rowColors.ts

@@ -1,3 +1,4 @@
+import { isQSLConfirmed } from '@/lib/qsl';
 // Row colouring for the log grid, by QSL status.
 //
 // Four categories, each scoped to the channels the operator cares about —
@@ -32,7 +33,9 @@ const FIELDS: Record<string, { sent: string; rcvd: string }> = {
 // ADIF QSL fields are single letters. Y is the only one that means "yes";
 // R (requested) and Q (queued) mean it has not gone out yet — a different state,
 // and the one an operator looks for when deciding what to send.
-const yes = (v: any) => String(v ?? '').trim().toUpperCase() === 'Y';
+// Y or V — see lib/qsl. A LoTW-verified contact is confirmed, and colouring it
+// as unconfirmed is the same bug the band/mode matrix had.
+const yes = (v: any) => isQSLConfirmed(v);
 const owed = (v: any) => {
   const s = String(v ?? '').trim().toUpperCase();
   return s === 'R' || s === 'Q';