v0.8.66: Remove blocking shell-manager locks from async TUI refresh paths

[Hmbown]

Problem

The async TUI loop calls blocking std::sync::Mutex::lock() on the shell manager while refreshing the Work sidebar and shell live-output state. If a background shell path holds that lock, the UI thread can block synchronously with no async yield.

Parent: #3800

Verified evidence

• crates/tui/src/tui/ui.rs: refresh_active_task_panel locks app.runtime_services.shell_manager with shell_mgr.lock().
• crates/tui/src/tui/ui.rs: refresh_shell_exec_live_output also locks the same manager with shell_mgr.lock().
• These calls run in UI refresh paths, so a contended lock can stop render/input polling until it is released.

Critical framing

This may be an amplifier rather than the primary fanout cause. Do not fix it with a broad, unmeasured thread offload. The target is to remove synchronous blocking from UI hot paths and prove the UI still paints while shell jobs are active.

Suggested implementation options

• Replace blocking lock calls in UI refresh with try_lock and skip/retain previous snapshot on contention.
• Maintain a shell-job snapshot updated off the UI path.
• Move shell-manager internals to async-aware locking only if the ownership model supports it cleanly.

Acceptance criteria

• UI refresh paths do not synchronously block on std::sync::Mutex::lock() for shell manager state.
• On contention, the UI keeps rendering and uses the last known shell/job snapshot or a bounded stale marker.
• Tests or instrumentation cover shell-manager lock contention during active sub-agent/background shell work.
• The 20-agent release gate in v0.8.66: Release gate for multi sub-agent fanout freeze #3800 remains input-responsive when child agents own shell jobs.

Security / policy guardrails

Removing blocking UI locks must not make shell state invisible to enforcement:

• try_lock/snapshot fallback is acceptable for rendering, but shell ownership, cancellation, approval state, and output capture must not depend on a successful UI refresh.
• If a shell-manager snapshot is stale, the UI should mark it stale rather than implying no shell is running.
• Do not loosen shell approval/sandbox behavior while moving UI reads off blocking locks.