FEATURE_BACKLOG.md: rett tre stale "ikke ferdig"-oppføringer

Massimport av spillere (ADR-082), kontosammenslåing del 2 (ADR-080) og
avstandsmåling/rangefinder-tråden (ADR-048/064/065/081/083/084) er alle
ferdig bygget og live, men filen sa fortsatt "påbegynt"/"ikke designet"
for dem. Oppdaget ved gjennomgang av backlogen på brukerens forespørsel.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

FEATURE_BACKLOG.md

@@ -3636,13 +3636,21 @@ retroaktiv hull-kort-handling. Skjema: ny `round_shot`-tabell (migrasjon
 alle endepunkter, delings-flyt med satellitt-bilde-generering) — se
 CHANGELOG.md punkt 37 for full detalj. Frontend delvis (Haversine-
 hjelper, delt `ClubPicker`, Mapbox-avhengighet + token-plumbing).
-**Gjenstår:** V0-eksport for selve `ShotMeasurementSheet` (prompt sendt
-til bruker, venter på svar), kobling av inngangspunktene i
-`round-detail.tsx`, reelle Mapbox-token i `.env` (kun tomme
-plassholdere satt inn foreløpig), ekte nettleserverifisering av
-kostnadskontroll-invarianten (ADR-048 Beslutning B), og til slutt
-utrulling til ekte database/containere (krever migrasjon 060 kjørt mot
-ekte `teecup_db` — IKKE gjort ennå, venter på eksplisitt bekreftelse).
+**RETTELSE 2026-08-18 — "Gjenstår"-lista under var stale, alt i den er
+nå ferdig:** `ShotMeasurementSheet` V0-integrert og LIVE (`shot/map-
+point-picker.tsx` er i dag en ferdig, produksjonsbrukt "klikk et punkt
+på kartet"-komponent, bekreftet gjenbrukbar i "Manuell koordinat-
+editor"-notatet lenger ned i denne filen), ekte Mapbox-token satt,
+migrasjon 060 rullet ut mot ekte `teecup_db`. Byggekjeden fortsatte
+dessuten videre til rangefinder-avstand til faste banepunkter
+(ADR-064/065, ADR-081) og et visuelt hull-diagram (ADR-083/084,
+2026-08-17/18) -- hele "avstandsmåling ligger i kortene"-ambisjonen
+denne brainstorm-tråden startet er nå bygget og live, ikke lenger et
+åpent spørsmål. ~~Opprinnelig "Gjenstår"-liste, beholdt for
+sporbarhet:~~ V0-eksport for selve `ShotMeasurementSheet`, kobling av
+inngangspunktene i `round-detail.tsx`, reelle Mapbox-token i `.env`,
+ekte nettleserverifisering av kostnadskontroll-invarianten (ADR-048
+Beslutning B), utrulling til ekte database/containere.
 
 **Se ADR-033 i ARCHITECTURE_DECISIONS.md for den fulle, besluttede
 arkitekturen** (eierskapsmønster, statistikk-datamodell, HCP-indeksmotor).
@@ -3913,7 +3921,7 @@ om å ikke fjerne historikk:**
 
 ---
 
-## Én person, flere e-postadresser — DEL 1 (det enkle tilfellet) ✅ BYGGET OG LIVE 2026-07-21, DEL 2 (kontosammenslåing) fortsatt 📋 NOTERT
+## Én person, flere e-postadresser — DEL 1 (det enkle tilfellet) ✅ BYGGET OG LIVE 2026-07-21, DEL 2 (kontosammenslåing) ✅ BYGGET OG LIVE 2026-08-17 (ADR-080)
 
 Reist av brukeren rett etter ADR-032 (verifisert e-postbytte). Et beslektet,
 men DISTINKT behov: én person kan ha flere e-postadresser i omløp samtidig
@@ -4014,18 +4022,16 @@ kjørt mot ekte `teecup_db` (bekreftet begge nye tabeller finnes,
 `/health`/`/dashboard`/`/account`/`/verify-email` → 200, `teeoff.no`
 upåvirket.
 
-### Del 2 (ekte kontosammenslåing) — fortsatt 📋 NOTERT, IKKE designet
+### Del 2 (ekte kontosammenslåing) — ✅ BYGGET OG LIVE 2026-08-17
 
-Uendret fra den opprinnelige analysen: hva skjer hvis adressen som legges
-til ALLEREDE er primær- eller sekundæradressen til en ANNEN, eksisterende
-konto (spilleren har altså to helt separate kontoer med egen historikk —
-ulike org-medlemskap, ulike spillerkoblinger, kanskje ulikt passord/2FA)?
-Dagens del 1-løsning avviser dette tydelig (409 DUPLICATE) i stedet for å
-gjette — en ekte sammenslåing (slå sammen org-medlemskap uten å bryte
-"én rolle per bruker per org", deduplisere spillerkoblinger, avgjøre
-hvilken konto som "vinner" for motstridende felt) er en betydelig større
-og mer risikofylt operasjon, fortsatt bevisst utsatt til en egen,
-dedikert designrunde.
+**RETTELSE 2026-08-18 — "📋 NOTERT, IKKE designet" var stale.** Bygget
+som ADR-080 (se ARCHITECTURE_DECISIONS.md): selvbetjent, "keeper"
+(initiativtaker, overlever) vs. "taper" (målet, slås inn og slettes),
+lenke sendt til MÅLETS e-post for å bevise eierskap (samme prinsipp
+som e-postbytte, ADR-032 Beslutning B), ny `account_merge_token`-
+tabell (migrasjon 077). Løser presist spørsmålet under (hva skjer når
+adressen som legges til allerede eies av en annen konto) -- avviser
+IKKE lenger med 409, tilbyr i stedet ekte sammenslåing.
 
 ---
 
@@ -4616,7 +4622,16 @@ skjema, eller begge), og om dette skal være en frittstående admin-side
 eller hektes inn i eksisterende baneoppsett-flyt i `courses.py`-relatert
 UI (se "Baneoppsett i turneringer"-seksjonen over).
 
-## Massimport av spillere til organisasjon/turnering (CSV) + redigerbar spillertabell — 🔨 PÅBEGYNT 2026-08-17
+## Massimport av spillere til organisasjon/turnering (CSV) + redigerbar spillertabell — ✅ HELT FERDIG, BYGGET, SCRATCH-/BROWSERVERIFISERT OG LIVE 2026-08-17 (ADR-082)
+
+**RETTELSE 2026-08-18 — "🔨 PÅBEGYNT" var stale.** Fullført samme dag:
+nytt bulk-endepunkt, CSV-parsing+kolonnegjetting
+(`player-import-panel.tsx`, orkestrering) + redigerbar tabell (V0-
+eksportert `player-import-view.tsx`, "stor skjerm først") -- første
+redigerbar-tabell-UI-mønster i kodebasen. Én reell integreringsbug
+funnet og fikset i scratch (V0s kjønn-nedtrekk brukte female/male/
+other, rå CSV-tekst måtte normaliseres ved kolonnetilknytningen). Se
+ADR-082/CHANGELOG.md 2026-08-17 for full detalj.
 
 Bruker ba om en måte å masseimportere spillere fremfor én-og-én, og
 spurte konkret om en tabell der ALLE felt er redigerbare. Research denne