Late-registering implement is never told to go to Auto if AOG enabled SC earlier #94

Summary

The "section control enabled" (Auto) state from AOG is applied once, when AOG's 0xF1 packet arrives. A client that registers after that packet is never told to switch to Auto, and its per-client state stays false.

This is a suspected robustness gap found while reading the logs for #93. No log shows it happening. In the #93 session the Sulky registered at 09:52:56 and AOG's enable arrived at 09:53:11, so the ordering was fine. (#93 itself turned out to be a hardware fault on the machine, unrelated to this.)

What the code does

• ClientState::isSectionControlEnabled defaults to false (include/task_controller.hpp:79).
• MyTCServer::update_section_control_enabled() is only called from the 0xF1 handler (src/app.cpp:473-479). It iterates the clients registered at that moment and sends DDI 160 (Section Control State) to each.
• Object pool activation (src/task_controller.cpp, around the "registered successfully" log) does not replay the last enable value to the new client.
• MyTCServer::update_section_states() skips any client whose flag is false ("setpoints only in auto mode"), so a late client also never receives section setpoints.
• The only other writer is the client's own DDI 160 report (src/task_controller.cpp:683-686), which is the machine's state, not AOG's.

Scenarios that could hit this

• AOG enables SC, then an implement is powered on or plugged in afterwards.
• An implement drops off the bus (or times out) and re-registers while AOG stays in Auto.
• The TC is restarted while AOG stays in Auto.

In each case the implement would stay in manual and get no setpoints, and the TC's 0xF0 heartbeat would report enabled = 0 for it.

Open question

Does AOG re-send 0xF1 periodically or on every heartbeat? If it does, this is self-healing and can be closed. If it only sends on a button press, the gap is real. docs/PROTOCOL.md does not say. Needs checking on the AOG side.

Suggested fix

Remember the last 0xF1 value on the server (or in Application) and apply it when a client's pool is activated with sections, i.e. call send_section_control_state() for it and set the client's flag. This should be a small change.

Test idea

Bench, no implement needed at the time of enabling: send 0xF1 = 1 from AOG (or a UDP script), then connect an implement with sections, and check that the log shows "Sending set value ... Section Control State ... Auto/on" without any further 0xF1 from AOG.