Claude review: drm/bridge: lock the encoder chain in scoped for_each loops

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

This is the most complex patch. The mutex lifecycle in the for_each macros is well-designed:

**`__drm_for_each_bridge_in_chain_next()`**: Gets the next bridge (incrementing its refcount), then conditionally unlocks the mutex only when we've reached the end of the chain (`!next`), then puts the current bridge. The ordering is correct — the next bridge's refcount is incremented before the current bridge is released.

**`__drm_for_each_bridge_in_chain_cleanup`**: Called via `__free()` when the loop variable goes out of scope (break/return). Correctly checks `if (_T)` to handle the normal loop-completion case where `_T` is already NULL (mutex was already unlocked in `_next()`).

**`__drm_for_each_bridge_in_chain_scoped_start()`**: Locks mutex, gets first bridge, unlocks if no bridges exist. This avoids leaving the mutex locked when there's nothing to iterate.

**Potential concern:** In `__drm_for_each_bridge_in_chain_from_start()`, the bridge is `drm_bridge_get()`'d before the mutex is locked. If the bridge is being concurrently removed from the chain (before the mutex is taken), the bridge struct remains valid due to the refcount, but its `chain_node` links could be poisoned. Since `drm_bridge_detach()` calls `list_del()` which sets the pointers to `LIST_POISON`, this could be problematic. However, the refcount prevents the bridge from being freed, and the mutex prevents concurrent chain modifications during actual iteration. The brief window between `drm_bridge_get()` and `mutex_lock()` should be safe because the caller is expected to already hold a reference to `first_bridge`.

No blocking issues.

---
Generated by Claude Code Patch Reviewer