fix GTK crash when switching to a driver that requires configuration

[knipknap]

Fixes #415

Problem

Selecting the Ruida driver in the machine settings crashed the app with

Gtk:ERROR:gtklistfactorywidget.c:114:gtk_list_factory_widget_setup_factory: assertion failed: (priv->object == object)

and because the driver choice is persisted immediately, every subsequent
start crashed too (crash loop). A related report in the comments showed
the driver being rebuilt on every keystroke while editing driver
settings, eventually wedging the connection until restart.

Root causes

1. BottomPanel._update_wcs_ui() force-refreshed the WCS dropdown by
   re-emitting items_changed(i, 1, 1) on an unchanged Gtk.StringList
   on every machine.changed. Faking item replacements violates the list
   model contract; GTK crashes with the above assertion when this happens
   while it is setting up factory widgets (e.g. during window build at
   startup, which is exactly the persisted-bad-driver crash loop).
2. LaserControlWidget._rebuild_head_model() replaced the head combo's
   entire model on every machine.changed, poking live widgets mid-flight
   in the same signal wave.
3. Machine.set_driver()/set_driver_args() scheduled a rebuild directly
   and triggered the controller's changed listener, so every
   configuration change ran two concurrent rebuild coroutines with two
   connection attempts. Per-keystroke edits therefore tore down/re-created
   the driver and transport repeatedly until things wedged.

Fixes

• bottom_panel: the WCS dropdown model is now spliced only when the
  displayed content (WCS set, labels, offsets) actually changed, via a
  real Gtk.StringList.splice() — legal list model usage, no more
  mid-flight poking.
• laser_control_widget: the head model is only swapped when the head
  names changed; otherwise just the selected head's fields are re-synced.
• controller/machine: driver rebuilds are now driven exclusively by
  the machine's changed signal (blinker) and debounced (0.3 s), so
  bursts of edits coalesce into a single rebuild and a single connect.
  Cancellation happens during the sleep and is re-checked afterwards, so
  a superseded rebuild can never touch driver state. A pending rebuild
  is also cancelled by disconnect() so it cannot silently reconnect an
  explicitly disconnected machine.
• controller (follow-up from testing feedback): while a driver is
  connected, editing its setup arguments no longer tears it down and
  reconnects. The live instance is kept; the edited arguments are applied
  by the rebuild that runs once the connection is gone again (explicit
  disconnect or a drop). This removes the remaining
  disconnect/reconnect churn when typing into numeric driver fields.
• disconnect(): resets the connection status immediately instead of
  leaving it stale until the scheduled rebuild runs.
• general_preferences_page: populate the driver settings group from
  the driver class registry instead of the live driver instance, which
  is still the previous driver while a rebuild is pending.

Tests

• New tests/ui_gtk/doceditor/test_bottom_panel_wcs_model.py: verifies no
  model mutation on unchanged state (the the app crash when switching to the ruida driver #415 crash) and a single real
  splice on offset/WCS-set changes.
• New TestDriverRebuildDebounce in tests/machine/models/test_machine_controller.py:
  a burst of set_driver_args calls results in exactly one rebuild with
  the final values.
• New TestKeepLiveDriverOnArgsChange: editing args of a connected
  driver keeps the live instance and connection intact, and the edited
  arguments are applied after a disconnect.

Full tests/machine (2266 passed) and uitest (853 passed) suites green,
pixi run lint/format clean.