F-34: JMRI config screen connect/disconnect faults #37

Severity: MEDIUM · Effort: Medium · Batch: 3 · Status: Code done in #21 (b35b84c), awaiting bench verification

Found in the second full review of the firmware. Recorded with the rest of the pass (F-19…F-44) in docs/REVIEW_REMEDIATION_PLAN_2.md, which is where its status is kept.

Description

• Disconnect runs on the LVGL task and blocks it for up to about two seconds.
• Disconnect does not stick: the reconnect task undoes it within five seconds.
• setWebPortCallback is registered after connect() has started the receive task, so it
  races the PW line.
• That callback reconnects the JSON client on the WiThrottle receive task, concurrently with
  the reconnect task — a possible double esp_websocket_client_destroy.
• A manual connect never updates JmriConnectionController's saved address or enables
  auto-reconnect, so later reconnects go to whatever was loaded at boot.

Plan

Route both the screen's connect and disconnect through JmriConnectionController, which owns
the saved settings, the auto-reconnect flag and the one task that connects.

Acceptance Criteria

• One task, jmri_conn, carries out every JMRI connect and disconnect, including the
  screen's; jmri_autoconn, jmri_reconnect and the screen's jmri_connect are gone.
• Disconnect and Connect return at once on the LVGL task; saving happens on the worker.
• Disconnect turns reconnecting off until the next Connect.
• The PW callback is registered once, before any connect, and only records the port;
  the worker saves it as json_port and moves the JSON client.
• A manual connect updates the settings the worker reconnects to.
• Under the orchestrator, Connect saves only (a one-shot jmri_save task; the shared
  SettingsWriter since batch 5, F-39).
• Bench: Connect, Disconnect (stays down past ten seconds), Connect again; change server
  address and confirm reconnects go to the new one.