Add firmware rollouts with per-miner update history

## Problem

Fleet can send firmware updates, but it does not have a first-class rollout workflow or durable history that ties a firmware payload to the miners it reached. Operators need to quickly answer:

- Which miners were targeted by a firmware update?
- Which miners completed the update, are still in progress, or need attention?
- Which firmware updates has a miner gone through?

Without this visibility, large updates are harder to operate safely and audit after the fact.

## Desired outcome

Add a dedicated firmware rollout experience in Fleet. Operators should be able to choose a firmware payload and a compatible group of miners, pace the update in controlled batches, monitor progress, and manage an active rollout when conditions change.

Each rollout should preserve per-miner status and a durable timeline. Active and completed rollouts should remain available so operators can inspect results, retry miners that need attention, and understand firmware update history across the fleet.

## What good looks like

- Operators can create and start a rollout for a compatible set of miners.
- Operators can control the rollout pace and pause, resume, or stop an active rollout.
- Fleet shows overall progress plus per-miner outcomes, attempts, and relevant error details.
- Completed rollout history and operator or system events remain available for inspection.
- Active rollout status is visible from the broader Fleet experience.
- The feature has appropriate permissions and auditability.

## Prototype reference

The [`rongxin/firmware-rollouts-prototype`](https://github.com/block/proto-fleet/tree/rongxin/firmware-rollouts-prototype) branch explores this workflow, including model-scoped rollouts, controlled batches, lifecycle controls, per-miner results, history, and global rollout status. Treat it as product and technical discovery rather than the final design.