[garrett-livefront]

Fixes #362.

The problem

MeshCore companions carry a "repeat" flag (the repeater-mode checkbox in the official app). The firmware sets it from the trailing byte of CMD_SET_RADIO_PARAMS and treats a missing byte as repeat = 0, then persists it. apply_radio_config_update called set_radio(freq, bw, sf, cr) without that byte, so every frequency / bandwidth / SF / CR change made through RemoteTerm silently turned repeat mode off on a node that had it enabled. There was also no way to see or set the flag from RemoteTerm.

The change

Two commits: backend + tests, then frontend + tests.

Backend

• RadioManager caches repeat_enabled, repeat_supported and allowed_repeat_freqs alongside the other device-query fields. They're read from the DEVICE_INFO reply (payload["repeat"], fw ver ≥ 9; raw-frame fallback at byte 80), and the allowed list from get_allowed_repeat_freq() in the same connect-time pass. A failed allowed-frequency query logs at debug and leaves the list empty; it never blocks connect.
• GET /api/radio/config returns repeat_enabled, repeat_supported and allowed_repeat_freqs (min/max MHz ranges). PATCH accepts repeat_enabled.
• apply_radio_config_update now always passes repeat= to set_radio when the firmware supports it: the requested value if given, otherwise the node's current value. This is the bug fix, and it applies to existing users who never touch the new checkbox. A repeat-only PATCH reuses the current freq/bw/sf/cr from self_info.
• The set_radio result is now checked. A firmware ERR (e.g. repeat requested on a frequency outside the compiled-in allowed list) becomes a 422 that quotes the node's own allowed list: Firmware rejected the radio settings (ERR_CODE_ILLEGAL_ARG). Repeat mode is only allowed on: 918.000 MHz. Sending repeat_enabled to firmware that doesn't report repeat returns 400, mirroring path_hash_mode.
• No new dependency; meshcore 2.3.7 already has set_radio(..., repeat=), the repeat parse, and get_allowed_repeat_freq().

Frontend

• "Repeater Mode" checkbox at the end of the Radio Parameters section, shown only when repeat_supported, with one line of help text. Diffed into the PATCH only when changed; included in config export/import like the other flags.
• A Compatibility Warning box (same style as the Path Hash Mode one) lists the firmware's allowed repeat frequencies and notes the list is compiled into the firmware and can't be changed from RemoteTerm.
• The checkbox is disabled when it's unticked and the entered frequency is outside every allowed range, so repeat can't be enabled somewhere the firmware will reject. It can always be unticked. If repeat is already on and the frequency is moved off-list, saving fails loudly with the 422 above rather than silently dropping repeat; that's deliberate.

Docs: the /radio/config rows in AGENTS.md, app/AGENTS.md and frontend/AGENTS.md are updated.

New radio setting UI

Error upon attempting to save radio settings with repeater mode enabled for an unsupported frequency

Testing

• ./scripts/quality/all_quality.sh green (pyright 0 errors, pytest + vitest passing, frontend build).
• New unit tests: repeat preserved on a param-only update; repeat-only update reuses self_info params; ERR → 422 quoting the cached allowed list; unsupported-firmware → 400; allowed list cached from payload and empty on ERR; checkbox shown/hidden, gated by entered frequency, always un-tickable.
• Hardware: tested over TCP against a companion on firmware v1.16.0 (companion protocol 13) whose build allows repeat only on 910.525 MHz. Confirmed: checkbox reflects the node; changing SF with repeat on keeps repeat on (previously cleared it, verified via DEVICE_QUERY byte 80); allowed list renders; off-list frequency with repeat on returns the 422 and leaves the radio unchanged; unticking at an off-list frequency saves the frequency change with repeat off.

Notes for the maintainer

Written with AI assistance per CONTRIBUTING.md; every change was reviewed and hardware-tested by me. AGENTS.md says agents never commit — the two commits here were produced by an agent on my fork and reviewed by me before opening this. Happy to squash or re-author if you'd prefer.