Move beaconing from Direwolf to DireControl

[StrangeWill]

Problem

DireControl currently relies on Direwolf's built-in beaconing to transmit APRS position packets. While DireControl already has the ability to send beacons on demand (POST /api/v0/radios/{id}/beacon via BeaconService), scheduled/periodic beaconing is still handled by Direwolf's configuration.

This is a problem because DireControl has no visibility into when Direwolf beacons. The status indicators in OwnStationPanel (green/amber/red based on time since last beacon) and the beacon confirmation pipeline (KISS echo detection, digipeater confirmation tracking) only work for beacons that DireControl itself initiates. Direwolf-originated beacons are invisible to this system, so:

• Status colors are inaccurate — the panel may show red/amber even though Direwolf just beaconed successfully
• Beacon history is incomplete — only manually triggered beacons appear in the history and confirmation tracking
• Confirmation tracking doesn't fire — the HopCount = -2 → confirmed pipeline in AprsPacketParsingService never gets a pending beacon to match against for Direwolf-originated beacons

Scope

Scheduled beaconing service

Implement a timed background service that periodically triggers BeaconService for each eligible radio at its configured interval (Radio.ExpectedIntervalSeconds). All beacons — scheduled or manual — flow through the existing pipeline (BeaconService → KissConnectionHolder → Direwolf KISS), so the full confirmation pipeline (KISS echo, digi confirmation, SignalR broadcasts, status indicators) works for every transmission.

Per-radio beacon enable/disable

Add a per-radio toggle (BeaconEnabled or similar) so each radio can independently opt in or out of scheduled beaconing. Radios with beaconing disabled should still support manual "Beacon Now" but are skipped by the scheduled service. The UI should expose this toggle in radio configuration.

Manual beacon remains unchanged

The existing POST /api/v0/radios/{id}/beacon endpoint and "Beacon Now" button continue to work as-is regardless of the scheduled beaconing toggle.

Out of scope

• SmartBeaconing — could be added later since DireControl would own the beacon timing
• Direwolf configuration changes — users are expected to remove Direwolf's beacon directives themselves when switching to DireControl-managed beaconing