F-42: Protocol hygiene odds and ends #45

Severity: LOW · 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.

• JmriJsonClient::requestPowerList (unused) treats a byte count as an error and blocks with
  portMAX_DELAY.
• Several OrchestratorClient lock-timeout fallbacks write shared strings unlocked.
• WebSocket continuation frames are accepted but the buffer is cleared per fragment (fails safe).
• getLayoutId always uses the first layout and is not cleared when the host changes.
• handleRosterMessage's warning can read past the end of a malformed message.

Acceptance Criteria

• requestPowerList removed.
• OrchestratorClient: connection, system and track-power states are atomics, so no lock
  timeout can lose a change. The session cookie, host and port are written only under
  the lock; a timeout fails the login rather than writing unlocked.
• A message split across frames is reassembled up to FIN before it is parsed.
• The layout id is forgotten on every login, and more than one layout is logged.
• JmriJsonClient's power-manager name, written on two tasks and read on a third, is
  under the power mutex.
• The roster warning no longer indexes past the end.