refactor(app): replace the _apply_to_live_widgets if/elif cascade with table dispatch

[wkentaro]

This was generated by AI during triage.

Context

Noticed while reviewing #2403, which expands the Settings dialog from 2 tabs to 5.

MainWindow._apply_to_live_widgets(key_path) is the single place that pushes a changed config key onto the live widgets. Every new settings row that applies immediately has to add a branch to it. After #2403 it is a ~12-branch if/elif cascade over key_path, covering color_theme, the five menu toggles, canvas.fill_drawing, canvas.crosshair, shape.show_labels, canvas.allow_out_of_bounds_points, shape.point_size, the two color keys, labels, flags, and the label-behavior group.

Problem

The cascade is the growth point for the whole settings feature: adding a row means editing this one method, so it accumulates unrelated reasons to change (canvas setters, dock rebuilds, label-dialog rebuilds, theming). It is a pre-existing shape, not a regression introduced by #2403, but that PR roughly doubled its length and made the trend visible.

#2403 already established the fix locally: it replaced five near-identical menu-toggle branches with a toggle_actions dict lookup. The same table-dispatch idea generalises to the rest.

elif key_path in toggle_actions:
    self._sync_action_checked(
        action=toggle_actions[key_path], checked=self._config[key_path[0]]
    )

Secondary nit in the same method: toggle_actions is rebuilt on every call even though it is a fixed mapping of key_path to QAction.

Suggested change

Map key_path to a small applier callable (dict, or a field on schema.Setting) so a new settings row registers its live-apply behaviour next to its schema entry instead of appending a branch here. Keep the genuinely multi-step cases (labels, flags) as their own named methods that the table points at.

Notes

• Non-blocking follow-up. It does not gate feat(settings): expose more preferences in the Settings dialog #2403.
• Behaviour-neutral refactor: covered by the existing per-tab e2e live-apply tests in tests/e2e/settings_test.py.

[wkentaro]

This was generated by AI during triage.

Agent Brief

Category: task (behavior-neutral refactor)
Summary: Replace the _apply_to_live_widgets key_path cascade with a dispatch table, so a new settings row registers its live-apply behavior rather than appending a branch.

Routing: ready-for-human, not ready-for-agent. Two blockers below make this undelegatable as written; both are resolvable, and once they are this becomes a good agent task.

Why this cannot go to an AFK agent yet

1. The premise does not exist on main. The ~12-branch cascade, the toggle_actions dict, and the canvas.fill_drawing / canvas.crosshair / shape.point_size / shape-color / label-behavior-group branches all live on the unmerged feat(settings): expose more preferences in the Settings dialog #2403 branch. On main, _apply_to_live_widgets has five branches (color_theme, shape.show_labels, canvas.allow_out_of_bounds_points, labels, flags) and no toggle_actions at all. An agent picking this up today faces three incompatible options (refactor the small main version and hope it composes; work against the unmerged PR branch; or no-op until it merges) with no way to pick correctly. This should be re-evaluated after feat(settings): expose more preferences in the Settings dialog #2403 merges, at which point the described code actually exists.

2. The applier-registration shape is an open design decision. The issue offers "dict, or a field on schema.Setting". These are materially different: Setting is currently a frozen, purely descriptive dataclass (key_path, section, label, kind, choices, choice_labels, note, beta) with no behavior hook. Adding a callable field would put widget-applying behavior into the config-schema module, which is a layering call, not an implementation detail. A maintainer should pick.

Desired behavior (once unblocked)

Dispatch on key_path through a lookup rather than a linear cascade. A settings entry with no live-apply behavior stays a silent no-op (today display_label_popup, language, and validate_label are in the settings table with no branch, and that is intentional: they take effect on next load/restart). Genuinely multi-step cases (labels, flags) stay as their own named methods that the table points at.

Constraints the refactor must preserve

• Call ordering. The applier runs only after the override is persisted and after self._config has been mutated in place. Several branches re-read self._config[...] rather than using the changed value directly, and labels/flags specifically read self._config[...] or [] (falsy-to-empty-list coercion). An applier signature that receives only the new value would break these; appliers need access to the live config.
• Prefix branches vs exact-key branches. labels and flags are written as first-element tests (key_path[0] == ...), not tuple equality. Mixed tuple arities (1-tuple ("color_theme",), 2-tuple ("shape", "show_labels"), 1-tuple group keys ("labels",)) all in one dict is the easy thing to get subtly wrong.
• Missing entry means no-op. Do not force every schema Setting to carry an applier, and do not "fix" the currently-unwired settings as part of this.
• On the feat(settings): expose more preferences in the Settings dialog #2403 branch there are three call sites, not one (_on_setting_changed, the revert-on-write-failure path, and the crosshair master-toggle fan-out). All three must keep working.

Acceptance criteria

• _apply_to_live_widgets dispatches through a table; adding a settings row does not require editing a cascade.
• The fixed key_path-to-QAction mapping is built once, not rebuilt per call.
• No observable behavior change: every setting that applied live before still does, and settings with no live-apply behavior still silently no-op.
• The full test suite passes.

Test-coverage caveat

The issue says this is "covered by the existing per-tab e2e live-apply tests". That is only partly true. On main, the settings e2e tests directly cover live-apply for shape.show_labels, labels, and flags, but not color_theme or canvas.allow_out_of_bounds_points. Several #2403-only cases (fill_drawing, crosshair, point_size, the color keys, ai.default, and the sort_labels/show_label_text_field/label_completion group) would likewise need coverage. A behavior-neutral refactor is only safe to the extent each moved branch is pinned by a test, so add the missing live-apply tests before moving those branches.

Out of scope

• Wiring live-apply for settings that intentionally do not have it (display_label_popup, language, validate_label).
• Changing which settings appear in the Settings dialog.
• Any change to feat(settings): expose more preferences in the Settings dialog #2403 itself; this stays a non-blocking follow-up.