research(bridge): upgrade Arc<Mutex<Translator>> to Arc<RwLock<Translator>> after #104 and #108 land

[bug-ops]

Description

Once #104 (split NotificationCache) and #108 (split lock from LSP round-trip) land, the remaining
Translator state held under lock will be almost entirely read-only during tool calls. At that point
replacing Arc<Mutex<Translator>> with Arc<RwLock<Translator>> will allow concurrent read
operations (hover, definition, references, etc.) to run in parallel without contention.

Issue #108 explicitly defers this — "No RwLock (all handlers need exclusive access until
this split is complete)" — making this the natural Phase 3 of the concurrency improvement arc.

Problem

After #108 lands, each tool handler will:

1. Acquire exclusive write access only for the short ensure_open prepare phase (~2 ms)
2. Release the lock before the LSP round-trip

At that point, using Mutex still prevents concurrent reads of the Translator config fields
(lsp_clients, workspace_roots, extension_map), which are all read-only after serve().

Expected Behavior

Read-only tool handlers (hover, definition, references, document_symbols, completions,
call_hierarchy, workspace_symbol_search, code_actions) acquire a read lock and run concurrently.

Mutating handlers (rename_symbol, format_document) acquire a write lock.

Actual Behavior

All handlers acquire an exclusive Mutex lock, serialising even concurrent read-only calls.

Implementation Sketch

1. Change Arc<Mutex<Translator>> to Arc<RwLock<Translator>> in mcp/server.rs and mcp/handlers.rs
2. Update read-only handlers: translator.read().await
3. Update mutating handlers: translator.write().await
4. Verify no lock held across .await in read path

Blocked By

#104, #108

Spec

.local/specs/001-rwlock-translator/spec.md

Environment

• Version: 0.3.6
• Branch: fix/translator-lock-starvation