The authoritative-shards DDL moveRange path completes through ShardingCoordinator, whose generic completion logging treats non-OK statuses as errors. An expected ErrorCodes::LockTimeout is therefore logged at error severity. DSI/workload log analysis interprets that entry as a workload failure and creates or reports a false failure ticket. The legacy moveRange path logged this expected timeout as a warning.

As part of this ticket, we should: 

1. Classify only ErrorCodes::LockTimeout completion statuses for MoveRangeCoordinator as warnings.
2. Keep unexpected coordinator errors at error severity.