F-35: Orchestrator roster refused above ~35 locos #38

Severity: MEDIUM · Effort: Small · Batch: 5 · 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

HTTP_RESPONSE_LIMIT is 8 KB and each LocoRecord is about 230 bytes (two UUIDs among its
fields). A truncated response is refused whole, so a larger roster leaves nothing selectable.

Plan

Raise the limit for the roster read (allocating from PSRAM), or parse incrementally keeping
only address and name.

Acceptance Criteria

• The roster is streamed. JsonArraySplitter hands each record over as it closes, and each
  is parsed alone with cJSON, so memory is bounded by one record (4 KB cap) rather than
  by the response.
• A record over the cap, or with no usable address, costs that loco only. A record cJSON
  refuses, a stream that is not an array of objects, or one cut short, refuses the whole
  roster, as before.
• At most 128 locos are kept, matching the loco state cache, with a warning past that.
• Unit tests test_roster_splitter_* (seven) pass on the board (they compile).
• Bench: a roster of more than 35 locos loads whole.