fix(gui): lock start-only fields on every surface, not just the page

[donislawdev]

What was wrong

A field marked start_only in fields.FIELD_DEFS must grey out for as long as a session runs
(conventions 7 and 21). That held for the Control page, whose form App._sync_running_ui
refreshes. It did not hold for a field rendered by a window: the Settings window owns a
separate ControlForm, and nothing re-read the running state for it.

So "Capture only the targeted traffic" (narrow_filter) stayed clickable for the whole session
whenever the Settings window was open before START. Ticking it did nothing until the next session.

Measured on the fake Tk, both orders:

order	before	after
window open, then START	state="normal" - editable all session	disabled + the "locked while running" note
START, then window opened	disabled (already correct)	disabled

The second row is why this never looked broken: the build path reads is_locked, so the field
came up right whenever the window was opened during a run. Only the already-open window was stale.

The fix

• SettingsWindow.refresh() refreshes its form's field states. It is ticked while the window is
  open, so the lock now heals whatever moved the state, not only start/stop.
• App._sync_running_ui() ticks the open windows, so the lock is immediate instead of up to one
  700 ms tick late.

The guard is the point

test_start_only_fields_are_locked_while_a_session_runs named duration and the filter combobox
by hand, so it tested two examples rather than the rule. That is exactly how narrow_filter
was added to the registry, shipped unlocked, and kept the suite green.

It now derives its subjects from FIELD_DEFS and resolves each one to the surface that renders it
(SECTIONS[].surface, with CHOICE belonging to App rather than to a form), and it opens the
Settings window before the session starts, which is the order that was broken. A fourth
start_only field cannot repeat this.

Verified by mutation: removing either half of the fix turns the test red.

Testing

python -m pytest tests on an elevated shell: 908 passed, exit 0.

Two earlier runs each lost one unrelated GUI test to an OS-level fault in the spawned test
subprocess (_Py_HashRandomization_Init failure once, MemoryError in the prelude once, both
with empty stdout, both green in isolation). A control run on master and a re-run on this branch
were both clean, so that is machine load, not this change.

🤖 Generated with Claude Code