Addresses the review finding on the cross-thread reads.
_enabled_plugin_not_running runs on the config-watcher thread and read two
mappings the render thread mutates. Catching RuntimeError was not a fix: it
turned a torn read into a coin flip between an unnecessary discovery scan and
a missed retry, which is the bug this PR exists to remove.
Both reads are now snapshots taken under the lock that guards their writes:
- plugin_manifests via a new PluginManager.discovered_plugin_ids(), which
copies the ids while holding the existing _discovery_lock. Discovery
rebuilds that mapping entry by entry, so an unsynchronised reader can see
it half-populated.
- plugin_display_modes under a new controller lock, taken at the only two
sites that mutate it (_register_loaded_plugin / _unregister_plugin).
The locks are never nested -- each snapshot is taken and released before the
next -- so this cannot deadlock against discovery, which holds _discovery_lock
while it rebuilds.
No cost on the per-frame path. Both mutation sites run during reconcile, which
is rare, and every hot-path read of plugin_display_modes is on the render
thread itself, same thread as the writes, so those stay lock-free.
Tests: the accessor returns a snapshot rather than a live view, and actually
takes the discovery lock (proved from a second thread, since an RLock is
reentrant on the owning one) so a later refactor cannot quietly drop it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01STMbQE4YctTacQXfbYqKuW
