fix: make beacons session-only, slower and QSY-aware (#171)

Forgotten beacons kept filling the chat while nobody was at the station.

- The two enable switches are session state now: they start off, are
  never read from preferences.xml and are always stored as "false", so
  neither a stored switch nor an older release reading a newer file can
  start a beacon. The in-code default was "on" and started a beacon
  whenever the file was unreadable or had no <beaconCQ> block.
- The minimum interval rises from 1 to 5 minutes; the bundled template
  ships 10 instead of 1. Smaller stored values are raised when the
  timer is scheduled.
- BeaconFrequencyGuard switches a beacon off once a logger-reported
  transceiver frequency lies more than 2 kHz from the one reported when
  the beacon was switched on. UCXLog RadioInfo and Win-Test STATUS feed
  it wherever they already set MYQRG/SECONDQRG. Without SO2R the single
  radio stands for both categories, with SO2R each radio for its own.

Manual (DE/EN), changelog, website and PROJECT_CONTEXT updated.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NJ1tUJVmWChD9V5Pg7uH8X

docs/PROJECT_CONTEXT.md

@@ -217,7 +217,9 @@ CR/LF framing, XML framing, ports/transports, callsign normalization and frequen
 - Automated-message loops must be prevented.
 - Cooldown/minimum-interval rules must be preserved.
 - A reply rejected before a complete valid TX item is queued must not consume cooldown.
-- Both category beacons share one timer, while their enable flags and templates remain profile-scoped and independent. The enable flags are observable runtime preferences: Settings changes and the `MyBeacon` status-chip action update them immediately, and every timer run reads their current values without restarting the timer or causing an immediate transmission. Only the explicit full settings write persists those flags; layout autosave deliberately leaves the on-disk functional state untouched.
+- Both category beacons share one timer. Their templates remain profile-scoped and their enable flags independent of each other. The enable flags are observable runtime preferences: Settings changes and the `MyBeacon` status-chip action update them immediately, and every timer run reads their current values without restarting the timer or causing an immediate transmission. The enable flags are session state and nothing else (issue #171): they start `false`, `readPreferencesFromXmlFile` never reads them, and every write stores `false` in the four unchanged XML elements so that an older release cannot start a beacon from a newer file. A beacon therefore has to be switched on in every program run and after every profile switch; an automatic reconnect within one run keeps the flags. Do not reintroduce a persisted or default-on enable state: the former in-code default `true` started a beacon whenever the file was unreadable or had no `<beaconCQ>` block.
+- The shared beacon interval has a minimum of five minutes (`ChatController.MIN_BEACON_INTERVAL_MINUTES`); the bundled template ships ten. Smaller stored values are raised when the timer is scheduled.
+- `BeaconFrequencyGuard` switches a beacon off when a logger-reported transceiver frequency lies more than 2 kHz from the frequency reported when that beacon was switched on. The reference is the frequency at switch-on, not the previous report, so slow tuning triggers it as well. Only the reports that also set `MYQRG`/`SECONDQRG` reach `ChatController.onTrxFrequencyReported` (UCXLog `RadioInfo` with TRX sync, Win-Test `STATUS` with QRG sync), on the UI dispatcher next to the QRG write; manual QRG entry never triggers it. Without SO2R the single reported radio stands for both categories; with SO2R radio 1 belongs to the main-category beacon and radio 2 to the second-category beacon. The 2 kHz limit is a constant, not a setting.
 - `MyBeacon` owns one aggregate thread-status entry for both categories (`off`, a partial `enabled/available` count, `on`, or `FAILED`). Its action disables all currently usable beacons if any is enabled, otherwise it enables all currently usable beacons. A disabled second chat is not usable and its dormant enable flag must not be changed by the aggregate action. Category-specific timer failures remain authoritative while the affected beacon stays active; independent switch changes cannot hide them. The status bar resolves the aggregate from current controller state when a queued UI update is applied, so a delayed timer snapshot cannot overwrite a newer manual switch. Open Settings views observe the same preference values, so changes from the status chip remain synchronized without a parallel UI state.
 - Current implementation/tests define the exact message markers and timer details.
 

docs/superpowers/specs/2026-11-04-live-beacon-control-design.md

@@ -2,6 +2,12 @@
 
 Freigegeben von Marc am 2026-11-04.
 
+> **Teilweise abgelöst durch Issue #171 (2026-11-11):** Die Beacon-Zustände werden nicht mehr
+> gespeichert und nicht mehr beim Profilstart geladen; jede Sitzung beginnt mit „aus“. Das
+> Mindestintervall beträgt fünf Minuten, und eine TRX-Frequenzänderung über 2 kHz schaltet die
+> Beacon ab. Der aktuelle Stand steht in `docs/PROJECT_CONTEXT.md` unter „Autoanswer / Beacon“.
+> Alles Übrige in diesem Dokument gilt weiter.
+
 ## Ziel
 
 Die beiden Beacon-Aktivierungsschalter wirken in der laufenden Sitzung sofort. Der gemeinsame