fix(transport): shared VISA transport overwhelmed by concurrent instrument publishers

[wharwood]

Problem

When a shared-transport device (e.g. the bidirectional EA PSB10000, which vends both a PSUDriverBase .source view and an ELoadDriverBase .sink view over one VisaDriver) has publishers/background daemons running on more than one of its Instro* views, each view's Instrument background daemon runs on its own independent thread with its own poll_interval, unaware of any sibling instrument sharing the same underlying transport.

TransportBase/VisaDriver (instro/lib/transports/) already serialize concurrent access with a per-call RLock, so wire bytes never interleave — but nothing limits the combined rate of commands issued against one transport. Two independently-polling views can issue back-to-back commands fast enough to overrun the physical device's command/error-queue buffer. On the EA PSB10000 specifically, SYST:ERR? is queried immediately after every write/query (EAPSB10000Visa._write_checked/_query_checked), and the device queues errors asynchronously (~10-15ms per manual, ~100ms empirically safe per tests/psu/ea/test_ea_psb10000_hardware.py) — so concurrent pollers can outrun that queue and corrupt/drop error-check reads.

This isn't PSB-specific: any device class that vends multiple category views over one shared transport (per the "device serving more than one category" pattern in AGENTS.md) is exposed to the same failure once more than one view runs a background daemon/publisher.

Fix direction

Add a minimum inter-command spacing enforced inside the transport's own locked critical section (TransportBase/VisaDriver), so it throttles at the shared-resource level regardless of how many Instrument instances/threads are contending for it. This generalizes to any shared-transport driver without touching per-instrument polling config or the Instrument daemon architecture.

Repro

• Construct an EAPSB10000Visa, get both .source (wrap in InstroPSU) and .sink (wrap in InstroELoad), attach publishers/background daemons to both, start() both with default poll_interval=1.0.
• Observe SYST:ERR? failures / dropped or garbled responses on the shared VISA line as both daemons' ticks race.

[tunglambk]

I spent a while on this and I don't think the concurrency framing holds up, so I wanted to leave the measurements here before someone builds a transport-wide throttle around it.

With the real VisaDriver and the real EAPSB10000Visa behind a mocked resource, the aggregate wire rate doesn't rise with contenders: one view polls at ~485 wire ops/s and two views at ~486, because write/read/query all hold the same RLock for the whole round trip, so two operations are never on the wire at once. The number of error checks that read the queue clean is identical at one, two and four workers (3 of 30 each), so contention isn't what causes the mis-read.

The defect looks like _check_errors reading SYST:ERR? immediately after the write while the instrument queues errors asynchronously, so the check can run before the error lands. That reproduces with a single instrument, and the repo already documents it in tests/psu/ea/test_ea_psb10000_hardware.py, which works around it with ERROR_QUEUE_SETTLE_SECONDS = 0.1.

Two options as I see them, both needing a call: settle or defer the error check in the driver, which changes semantics the hardware test pins and needs the bench unit to validate; or a per-device delay following the existing write_delay_ms precedent on the Modbus timing config. Either way, if a throttle gets added anywhere, it's a rate limiter for slow devices, not a concurrency fix.

All of the above is mocked-transport — I don't have a PSB here. Happy to paste the reproduction scripts if they'd help.