v2.7.3: Flight logbook safety net, radar/clock/timezone fixes

New:
- Flight logbook safety net: disabled by default, requires confirming
  a full-screen warning before it can be turned on, and automatically
  switches off again after exactly 24 hours - survives restarts and
  power cycles (no valid enable timestamp = guaranteed off). Each
  activation now writes its own CSV file instead of endlessly
  appending to one growing file, and every file can be deleted
  individually from Logbook files.
- Adjustable display brightness (10-100% in 10% steps, Menu -> System
  -> "Brightness") with a live preview.
- About screen (Menu -> System -> "About") showing project name,
  description, and firmware version.

Fixed:
- Radar's red altitude band (>9100m/30000ft) no longer gets dimmed at
  night - the previous dim tone looked orange-brown and was hard to
  tell apart from yellow. Legend and markers are consistent again.
- Radius change no longer leaves a stale "tail" trail behind each
  aircraft between the old and new position.
- Splash screen no longer shows a time-of-day greeting that appeared
  too late in the boot sequence to be useful; the star animation now
  starts immediately instead of only near the end of boot.
- Clock stayed on raw UTC after the first boot instead of local time
  (missing DST handling in some timezones) because the location wait
  loop skipped the timezone lookup once a location was already saved.
- Header clock no longer leaves stale digit fragments behind the
  current time, most visible on the last minute digit.

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

CLAUDE.md

@@ -159,6 +159,18 @@ gefragt wird.
 Sobald der Workflow explizit angefordert wurde, automatisch folgende Schritte
 in dieser Reihenfolge:
 
+0. Versionsnummer festlegen: Die neue Versionsnummer kommt IMMER exakt von
+   Alex - er nennt sie im Push-Wunsch (z.B. über Claude/den Sandbox-
+   Assistenten: "Alex will auf Version X.Y.Z pushen"). Karl trägt GENAU
+   diese Nummer in `Config::APP_VERSION` (`src/config.h`) ein - niemals
+   selbst hochzählen, erraten oder von der letzten Version ableiten (auch
+   nicht bei kleinen Patches). Das gilt auch für größere Sprünge (z.B.
+   2.6 -> 3.0), die Alex bewusst und absichtlich machen kann - Karl
+   übernimmt in jedem Fall die genannte Nummer 1:1, ohne eigene Annahmen.
+   Falls im Push-Wunsch keine explizite Versionsnummer genannt wurde, bei
+   Alex nachfragen statt zu raten. Erst NACH dem Eintragen der korrekten
+   Nummer: einmal sauber `pio run` bauen, DANACH erst der Rest des
+   bekannten Workflows (README, Tag, index.html, Bin-Dateien, Commit/Push).
 1. Prüfen, ob seit dem letzten Commit neue/geänderte Features hinzugekommen
    sind, die für Endnutzer sichtbar sind (neue Menüpunkte, geändertes
    Verhalten, neue Screens) - falls ja, **README.md entsprechend ergänzen**