Triggering another update while "update all" is running shouldn't lock the process out

Source: Reddit feedback (u/Stubborninmate, 2026-06-15).

Request: If a user triggers another update while upgrade --all is already running, the app shouldn't lock the process out — it should queue the new request (or clearly surface that an upgrade is in flight and offer to queue/cancel) instead of silently blocking or wedging.

Notes for implementation:

• Today a second concurrent brew write-action can be rejected/blocked; define explicit behavior: queue subsequent update/install actions behind the running one, or disable+explain with an in-flight indicator.
• Single in-flight brew write lane is correct (brew isn't safely concurrent), but the UI must not appear frozen — show queued state and allow cancel.
• Pairs naturally with the % progress request (same Activity surface).
• Parity: both shells (Tauri + native).

Related: #90 / #47 / #13.

Start by tracing update and install action handling in both the Tauri and native shells, then inspect the Activity surface and the existing single in-flight brew write lane. Define and implement the chosen queued or explained-disabled behavior, including cancellation and visible in-flight state; done means a second action no longer silently blocks or wedges in either shell.