Cross-platform support: headless mode + Linux/macOS CI

[chriskinal]

Summary

Three related asks to unblock cab-side deployment of AOG-TaskController on non-Windows machines, particularly small Linux SBCs in tractor cabs.

1. Headless / console-mode entry point so the TC can run as a Linux service (or macOS launchd job) without an X11 / tray dependency.
2. Linux release job in the GitHub Actions matrix, using AgIsoStack++'s existing SocketCAN integration.
3. macOS release job for users running PCAN/Kvaser CAN adapters on macOS.

Context

`AgOpenGPS-Official/AgValoniaGPS` (the cross-platform Avalonia rewrite — Windows / macOS / Linux / iOS / Android) is evaluating ISOBUS integration via the existing PGN-over-UDP wire format that AOG-TaskController already exposes (heartbeat 0xF0, request 0xF1, process data 0xF2, field name 0xF3). The integration on AgValonia's side is platform-agnostic — it's already a UDP client.

The blocker for shipping that integration is TC binary availability outside Windows. Today only `AOG-TaskController-X.Y.Z-win64.exe` is published. AgValonia's primary in-cab platforms (iPad, Android tablet, Mac mini) can't run TC locally and can't host an X11 tray app on a Pi either.

Tracking issue on the AgValonia side: AgOpenGPS-Official/AgValoniaGPS#227

What's already in place

• AgIsoStack++ already supports SocketCAN on Linux. CAN driver layer is largely solved.
• The existing TC logic (`task_controller.cpp`, `udp_connections.cpp`, `settings.cpp`) is platform-agnostic; only `main.cpp` is Windows-specific (`shellapi.h`, `WndProc`, `TRAY_ICON_ID`, `WinMain`-style entry).
• Configuration is already file-based (`settings.json`) — no runtime UI required for normal operation. The current tray app is cosmetic; users rarely interact with it after AgIO launches it.

Suggested shape

1. Headless entry point

Refactor `main.cpp` to support both a Windows tray shell and a plain `int main(int argc, char** argv)` console mode. CMake target option (e.g. `-DBUILD_TRAY_UI=OFF`) selects which entry compiles. Console mode reads the same `settings.json`, runs the same TC logic, and exits cleanly on `SIGTERM`/`SIGINT` (or `Ctrl-C`).

Settings path resolution should fall back from `%APPDATA%` (Windows) to `$XDG_CONFIG_HOME/AOG-Taskcontroller/settings.json` (Linux) and `~/Library/Application Support/AOG-Taskcontroller/settings.json` (macOS).

2. Linux CI

Add a `linux_release` job to `.github/workflows/release.yml`. With AgIsoStack++'s SocketCAN backend, this should be roughly:

```yaml
linux_release:
runs-on: ubuntu-latest
steps:
- checkout (with submodules)
- cmake -S . -B build -DBUILD_TRAY_UI=OFF -DBUILD_EXAMPLES=OFF -DBUILD_TESTING=OFF
- cmake --build build --config Release
- upload tar.gz of built binary + sample settings.json + systemd unit file
```

A sample `aog-taskcontroller.service` systemd unit in `resources/` would let users `systemctl enable` the TC on a Pi.

3. macOS CI

Same shape on `macos-latest`. Driver caveat: PCAN macOS support exists but is paid; Kvaser has free macOS drivers. Worth checking which adapters AgIsoStack++ supports on Darwin before promising full parity. Even just a PCAN-only macOS build is useful.

Deployment story this unlocks

Operator's iPad / Android tablet runs AgValonia → cab Wi-Fi → small Linux SBC (Pi, BeagleBone) running `aog-taskcontroller` as a systemd service, attached to a USB-CAN adapter on the implement bus. Pure-LAN, no Windows companion box, identical setup pattern to other cab modules.

What this is not asking for

• No GUI work. The tray UI can stay as the default Windows packaging.
• No new ISOBUS features.
• No changes to the wire protocol with AgOpenGPS / AgValoniaGPS.

Just: same TC logic, additional packagings.