fix(registry): lock ModeRegistry lazy-load resolution against concurrent first access

[ErenAta16]

Summary

Fixes #2422. ModeRegistry.get_handlers() has an unguarded check -> pop -> import -> set sequence over self._handlers and self._lazy_loaders (plain dicts shared across threads on the module-level mode_registry singleton). On the first concurrent access to a given (provider, mode) key in a process, one thread pops the lazy loader and starts the module import; every other thread that already passed the mode_key not in self._handlers check then finds the loader also already popped from self._lazy_loaders, and raises KeyError (surfaced elsewhere as RegistryError) for a mode that genuinely is registered, just not finished resolving yet. Root cause and regression bisection (introduced between 1.15.2 and 1.15.3 when the v2 lazy-loading registry landed) were already thoroughly diagnosed in the issue.

Fix

instructor/v2/core/registry.py: wrapped the lazy-load resolution in a lock, with a re-check inside the lock so a thread that waited for another's in-flight load reuses the result instead of raising. Held for the full resolution rather than a per-key lock, since lazy-loading only ever runs once per key ever (subsequent calls hit the fast mode_key in self._handlers check before acquiring anything), this is a one-time cost per key at first use, not an ongoing bottleneck.

Testing

Added test_get_handlers_concurrent_first_access_does_not_race to tests/v2/test_registry.py, using a fresh ModeRegistry() instance (not the global singleton) with a loader that sleeps briefly to simulate a slow import, and a Barrier so all 8 worker threads call get_handlers() as close to simultaneously as possible.

Verified this is a meaningful regression test, not just a test that happens to pass either way:

• Against unfixed registry.py: 7 of 8 threads raise KeyError (reproduces the issue's exact failure mode).
• Against the fix: all 8 threads get the same ModeHandlers instance back, and the loader runs exactly once (asserted via a counter).

Ran the full tests/v2/ suite locally: 1578 passed, 1 pre-existing unrelated failure (test_vertexai_process_helpers_build_tools_and_config, missing optional jsonref dependency in my environment, nothing to do with this change), 170 skipped.