Cycle spinbox silently clamps and overwrites config values above 10000ms

[N6RFM]

Alex,

While experimenting with radio update timings of > 10000 msec, I also used the Claude LLM to help me adjust the upper limit,
The results reported back are below.

73,
Bob
N6RFM

Summary

The rotator and radio control windows' "Cycle" spinbox is created
with a hardcoded maximum of 10000 (10 seconds):

ctrl->cycle_spin = gtk_spin_button_new_with_range(10, 10000, 10);

(present identically in both src/gtk-rot-ctrl.c and
src/gtk-rig-ctrl.c)

If a saved config's Cycle value exceeds 10000, it is silently
clamped down by GTK when the spinbox is populated at startup — and
that clamped value is then written back into the in-memory config
via the spinbox's own "value-changed" handler, so the intended
higher value is lost from that point on, not just visually.

Steps to reproduce

1. Manually set a rotator's .rot config file to Cycle=15000.
2. Open Gpredict and select that rotator device in Rotator Control.
3. Check the displayed Cycle value.

Expected: Shows 15000, or Gpredict refuses/clamps the value
consistently (e.g. at config-save time, with a warning), rather than
silently accepting an out-of-range value in the file and only
discovering the limit at display time.

Actual: The spinbox shows 10000. Any further save-triggering
action (e.g. closing the Rotator Control window, which calls
rotor_conf_save()) persists 10000 back to the .rot file,
permanently losing the originally configured 15000.

Why this matters beyond the immediate surprise

This clamp-and-writeback happens through the exact same
delay_changed_cb side-effect path responsible for masking
[the rotor display timer bug reported separately] — rot_selected_cb
calls gtk_spin_button_set_value() on the Cycle spinbox using the
saved config value, GTK clamps it to the widget's range, fires
"value-changed", and the handler writes the clamped value back into
ctrl->conf->cycle. Anyone who wants a Cycle value above 10 seconds
for either the rotor or radio controller hits this immediately and
silently.

Suggested fix

Raise the hardcoded maximum in both files to a value with reasonable
headroom, e.g.:

ctrl->cycle_spin = gtk_spin_button_new_with_range(10, 30000, 10);

Verified in a sandboxed test: with the range widened, a config value
of 15000 is read, displayed, and retained correctly, where it was
previously silently clamped to 10000.

Happy to open a PR with this change if useful.

[N6RFM]

Related to #423 — the write-back through delay_changed_cb described here is the same side-effect mechanism that accidentally masks the timer bug in #423 for users whose saved Cycle value happens to differ from the spinbox's construction default.