F-29: Documented lock order is the reverse of what the code does #32

Severity: MEDIUM · Effort: Small · Batch: 4 · Status: Done in #21 (1b8767b) — documentation only, nothing to bench; closes when #21 merges

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

CLAUDE.md (hard constraint 3) and THREADING_MODEL.md say m_stateMutex before
lvgl_port_lock, and the threading diagram shows uiUpdateCallback running inside the state
lock. The code does the reverse throughout and does it consistently: onUIUpdateNeeded takes
the LVGL lock and then getThrottleSnapshot takes the state mutex, and every LVGL event handler
calls into the controller the same way; the controller never calls out to the UI while holding
its own mutex. A contributor following the documented rule would introduce the deadlock it
claims to prevent.

Plan

Correct CLAUDE.md, THREADING_MODEL.md (text and diagram), and any other copy of the rule to
"LVGL lock before m_stateMutex; the controller never calls the UI while holding its mutex".

Acceptance Criteria

• CLAUDE.md hard constraint 3, THREADING_MODEL.md (text and sequence diagram),
  .claude/agents/firmware-review.md and CONTROLLER_LAYER.md all state the order the code
  uses. No copy of the old rule remains.