Deployments page: what is live, where it came from, and how each node took it #1786

Part of HarperFast/create-harper#143.

Problem

Config → Deployments (src/features/instance/config/deployments/) was built for 5.1's deployment records. Since then:

• Staging. A deploy can be staged and made live later (5.3.0). A staged record has the status staged, and the activation's record carries activated_from.
• Going back. Going back to a release is an activation of its id (5.3.0), and it writes a new success record with activated_from. Nothing sets rolled_back or rollback_of, though the detail view still shows them.
• Install comparison. Each node's entry in peer_results says whether it installed what the origin did (5.3.1). install_matches is the verdict, and install_differs names the source or lockfile that differed. The record holds the origin's install_fingerprint.
• Certification. A restarting deploy is certified on each node (5.4.0).
• CI deploys. A deploy from CI runs as the trust policy's user.

Studio's types have none of these, and staged isn't a status it knows. The list fetches the newest 100 records with no filter or paging, and the detail view is read-only.

So the page can't answer what people come to it for: what is live on each node right now, what it was built from, and what they can go back to.

Proposal

1. Types. Add types and statuses for the 5.3+ fields.
2. List.
   • Filter by component and status.
   • Page with limit and offset. There's no server-side default limit.
   • Show the id, component, status, source (package reference or payload hash), user and time.
   • Show a staged record as waiting to be activated, and have an activation name the release it activated.
3. Detail. Show a row per node with its outcome, whether its install matched the origin's and what differed, and its certification.
4. Per component. Mark the live release and the releases each node keeps. These are what a rollback (Studio: Roll back to a previous deployment #1232) or an activation (Stage a release now and activate it later #1787) can target.
   • Kept and staged releases share deployment.stagingRetention.maxCount, which defaults to 5.
   • A release made live before 5.3.0, or deployed from a file: directory, isn't kept.
5. From the editor. Link an application in the Applications editor to its deployments.

Needs from Harper

• Nothing reports what is live on a node, or which ids it keeps. Activating an id a node doesn't keep answers 404. Until Harper can be asked, item 4 can only infer targets from list_deployments and the retention count. Tracked in Report which deployment is live on each node, and which releases each node keeps harper#3059.
• The record doesn't learn how a rolling rollout ended. It says success once the receiving node has the release, before the job reaches the others (Show canary certification and each node's outcome when a deploy restarts #1785). Tracked in A rolling deploy's record says success even when another node rejects the release harper#3060.
• A payload deploy records its hash, not the commit it was built from. To show "deployed from by ", the deploy needs to carry that information, as Record preview metadata on a deployment, and expire previews harper#3048 does for previews. Tracked in Record where a deploy came from: the commit, the CI run and the trust policy harper#3061.

Done when

Take a component deployed several times, including once staged and activated later, and once from CI. The page shows which release is live on each node, what each release was built from, how each node took it, and which releases can be gone back to.