Make SCPI send/read atomic (non-atomic send-read pair allows response crossing)

[RFingAdam]

Add asyncio.Lock around _connections, _current_template, and other shared mutable state in tools.py to prevent race conditions in concurrent MCP tool calls.

Acceptance Criteria

• asyncio.Lock instances for connection state, template state, measurement state
• All reads/writes to shared state use async with lock:
• No deadlock risk (consistent lock ordering)

[RFingAdam]

Re-verified against current code: partially done. tools/shared.py has three asyncio locks (_connection_lock, _template_lock, _measurement_lock, lines 54-56) protecting shared mutable state at the tool-dispatch layer. However, at the transport layer, driver/scpi_socket.py::SCPISocket.send() (line 123) acquires self._lock for the write, but read_response() (line 137) does not acquire any lock, and query() (line 171) calls send() then read_response() as two separate lock scopes. This means the send→read pair is not atomic: two concurrent query() calls sharing one pooled connection can interleave as send-A, send-B, read-A (gets B's response), read-B (gets nothing/wrong data) — silent response crossing, not a crash. Retitled to describe the actual remaining defect. Tracked under F1 (v0.4.0 Foundation), which introduces a transaction() primitive making send→read atomic plus desync detection/recovery.