Prevent overlapping bulk actions on the same devices

## Problem

There is no mechanism to prevent a user from issuing multiple bulk actions that target overlapping devices.
For example:
- Select all miners, click "Sleep", then immediately click "Wake Up" on the same set
- Start a firmware update on 50 miners, then trigger a reboot while the update is in progress
- Double-click an action button, creating two identical batches

The server-side queue enforces per-device FIFO ordering (no concurrent execution), so there is no
data corruption risk. But the UX is confusing: users see multiple in-progress batches, conflicting
status indicators, and the final device state may not match their intent.

## Current Behavior (updated 2026-08-04, audited against `main` @ `eb21f89ee`)

Still unaddressed. The client-side tracking has since moved into a Zustand store, but nothing consumes it to guard actions:

- Batch state lives in `client/src/protoFleet/store/slices/batchSlice.ts` (`byBatchId`, `byDeviceId`), queried via `getActiveBatches(deviceId)` in `store/hooks/useBatch.ts`.
- `byDeviceId` is consumed only for display and lifecycle: the status column in `MinerStatus.tsx` (which renders only the *first* active batch even when a device has several — see the "show first batch when device has multiple active batches" test) and batch polling/cleanup in `Fleet.tsx`.
- The bulk action surfaces (`MinerActionsMenu`, `BulkActionsWidget`, `FleetGroupActionsMenu`, `DeviceSetActionsMenu`) disable actions only for permissions, unauthenticated miners, and filtered select-all limitations — never because selected devices have in-flight batches.
- Dispatch in `useMinerActions.tsx` calls the API and `startBatchOperation` immediately, with no pre-check and no double-click guard on the initial action buttons (only the retry toast button has one). Confirmation dialogs exist for destructive actions but don't consider in-flight work.
- Server side is unchanged: batches are always accepted (`server/internal/domain/command/service.go`), and per-device FIFO is enforced in the queue (`GetMessagesToProcess` in `server/sqlc/queries/queue.sql`). No conflict rejection at batch creation.
- PR #611 keeps the in-progress status visible until the device reaches its expected state, which improves visibility of overlapping batches but does not prevent issuing them.

## Expected Behavior

Disable or guard bulk actions when the selected devices already have an in-flight operation.
For reference, GitHub disables bulk actions on issues/PRs while one is already in-flight
and re-enables them once it completes.

## References

- Originally tested on: v0.2.5-rc.1; re-verified on `main` (`eb21f89ee`, 2026-08-04)
- Ported from: btc-mining/proto-fleet#1590
- Related: #611 (bulk action status visibility until completion)

---
🤖 Current Behavior and References sections updated by AI agent on 2026-08-04 after a codebase audit.