https://teecup.golf → 200 OK, servert av teecup_frontend (Next.js)
https://teecup.teeoff.no → 301 permanent redirect til https://teecup.golf/, som deretter gir 200 OK
Let's Encrypt-sertifikater for teecup.golf og www.teecup.golf er utstedt og aktive
teeoff.no selv er upåvirket (samme Caddyfile, ingen endring i den blokken)
Rotårsaken til at det ikke virket tidligere var ikke feil i selve Caddyfile-innholdet (den var allerede korrekt på disk), men en klassisk Docker-fallgruve: filen på verten hadde blitt erstattet (ny inode via "skriv ny fil + rename"), mens Caddy-containerens bind-mount fortsatt pekte på den gamle, nå "foreldreløse" filversjonen. caddy reload leser fra samme stale mount og hjelper derfor ikke i et slikt tilfelle — det krever en full container-restart for å remonte fra gjeldende fil. Det forklarer trolig også hvorfor de to reload-forsøkene fra TeeCup-siden var no-ops.
backend/weather_forecast.py: weather_sync_loop tar nå en valgfri on_updated-callback som kalles etter hver synkroniseringsrunde, men kun når noe faktisk ble oppdatert.
backend/main.py: sender inn invalidate_public_api_caches(include_place_pages=True) som denne callbacken når værsynken startes ved oppstart.
api-containeren er restartet og kjører rent.
Effekten: neste gang værsynken faktisk endrer noe (skjer omtrent hver time), tømmes backendens interne cache og frontendens unstable_cache for anleggslisten/steds-sidene automatisk — så "Ikke regn meldt"-filteret vil vise fersk værdata i stedet for en fastfrosset snapshot.
Dekker MinIO offentlig bildelesing (ADR-018) og WebSocket-trafikk til
teecup_api (ADR-025, Kommunikasjon) -- begge allerede live siden sine
respektive runder, kun ikke committet før nå.
