namir-worker: try_submit is documented as never blocking but takes a lock held for up to 2 s

[ErwanLegrand]

crates/namir-worker/src/submit.rs:81-82

try_submit calls self.lock() (submit.rs:139, a plain Mutex::lock), and submit_with_deadline (:113) holds that same guard across its entire sleep/retry loop until DEFAULT_DEADLINE (2 s).

The doc says "One attempt, never blocks. This is what the UI thread uses", and Instance::try_submit_param (lib.rs:320) repeats it; namir-clap/src/ui_host.rs:189 and namir-app/src/host.rs:420 both cite that claim from the GUI thread.

Scenario: a host deactivates a plugin (ring stops draining, consumer still alive), a worker Instance::load enters the 2 s wait holding the producer mutex, the user moves a knob -- the GUI thread stalls up to 2 s inside a "non-blocking" call. That is the D-15.3 / FR-UI-060 violation namir-clap/src/audio.rs:14-19 explicitly reasons about for the audio thread but never for the GUI thread.

lib.rs:755 try_submit_param_never_blocks_on_a_full_ring is single-threaded and only exercises the full-ring path, never the contended-mutex path -- so the property the doc asserts is checked by nothing.

Fix: try_submit should use producer.try_lock() and return the command on contention.

[ErwanLegrand]

PARTIAL — leaving open, and correcting an earlier claim on PR #145 that this was fixed.

What landed (ba436e2, e914e11): submit_with_deadline no longer holds the producer mutex across its wait — attempt() takes and drops the guard per push (crates/namir-worker/src/submit.rs:206-213), and try_submit now spins LOCK_SPIN_ATTEMPTS = 256 try_locks instead of lock() (submit.rs:145-156), so the GUI thread's wait on that mutex is bounded by a fixed instruction count rather than by another thread's 2 s deadline.

What is untouched is the user-visible symptom. Instance owns its CommandSubmitter by value and every method takes &mut self, so neither shell reaches try_submit except through an outer Mutex<Instance>: namir-app's SharedInstance::with (crates/namir-app/src/instance.rs:41,52-56) and namir-clap's SharedInner::with_instance → lock_instance (crates/namir-clap/src/shared.rs:591,601), both plain blocking lock(). Because access is already serialised there, producer.try_lock() cannot return WouldBlock in production at all — the narrowed hold is a correctness cleanup, not a fix for the reported stall.

The live FR-UI-060 / D-15.3 violation is one level up: ClapUiHost::set_param (crates/namir-clap/src/ui_host.rs:243) blocks on the outer mutex, and worker_jobs.rs:60 holds that same mutex across Instance::load — a worker-thread call that reads and parses a file. A knob moved during a model load still stalls the GUI thread for the whole load, and nothing in this PR touches that.

---

Generated by Claude Code