F-30: Transport callback slots unsynchronised and clobbered by the UI #33

Severity: MEDIUM · Effort: Medium · Batch: 1 (clobbering), 5 (synchronisation) · Status: Code done in #21 (29b54d2), 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

On WiThrottleClient, JmriJsonClient, WiFiManager and ThrottleController, a
std::function (or function pointer and userData pair) is assigned on the LVGL task and
invoked in place from network tasks, so a torn pair or a closure destroyed mid-call is possible.
Separately, MainScreen and JmriConfigScreen overwrote the WiThrottle client's single
connection slot that the backend owns — the F-08 problem the orchestrator screens were written
to avoid. OrchestratorClient copies callbacks under its mutex and invokes the copy; that is
the pattern to follow.

Plan

1. Batch 1: stop the UI taking backend-owned slots (see F-21).
2. Batch 5: copy-under-lock for every remaining slot.

Acceptance Criteria

• No UI class takes a client's connection slot (batch 1).
• Every slot on WiThrottleClient, JmriJsonClient, WiFiManager, OrchestratorClient,
  both backends and ThrottleController is a CallbackSlot (main/utils/CallbackSlot.h):
  set under its own lock, invoked as a copy with the lock released. The controller's
  function-pointer-and-userData pairs are one closure each, so they cannot tear.
• OrchestratorClient's lock-timeout fallbacks that read a slot unlocked are gone with the
  slots they read.
• Unit test test_callback_slot_invokes_a_copy passes on the board (it compiles).