Seal the install timing as a classed, signed artifact

[LamplighterPaul]

Stacked on #177; the change to review is the last commit (2a02b6b). Plan: #134.

Why

A leaderboard needs to know which class a result belongs to and that the file it is shown was not edited after the install. Both have to be decided at the finish line, in the live environment, by the installer that observed the run. Nothing about this contacts a server: sharing a result is a separate, explicit step on the installed system, and comes later in the omarchy repo.

What

• A run_id (UUIDv4) is minted before the first phase, so a failed run has a name in its log too, and the finish screen shows its first eight characters beside the lap time as the run code: 1:18.188 #8dae647e. A photo of the screen can be matched to the sealed document on the target. It moved here from Show install duration with explicit units and sub-minute milliseconds #177 because that is its only job.
• The timing document gains the ISO's identity (iso_ref, mirror, sha256 of the offline database), the release installed, the class the installer observed (full_disk or protected, encrypted, virtualised, page cache warmed) and a hardware sketch: vendor, product, board, CPU model, memory, target disk and install medium by model, transport and size. No serials, UUIDs, MACs, hostnames or usernames. It is written to /var/lib/omarchy/leaderboard/timing.json as well as the timing log, same bytes in both.
• After the last phase an Ed25519 keypair is generated with the openssl CLI, the document on disk is signed, and timing.sig and install.pub land beside it. The private key is fed to openssl on stdin and never written; it is gone at reboot. On a btrfs target the three files are copied into the @factory snapshot too.
• Every probe and the seal itself are best-effort. A failure leaves the plain timing file and a line in the install log, never a failed install.
• Anyone can check a result with openssl pkeyutl -verify -pubin -rawin -inkey install.pub -in timing.json -sigfile timing.sig. Sealed means tamper-evident, not true: a document and a keypair can be fabricated on any machine. Anti-cheat is class isolation and review on the server side, not this file.

How tested

• ./test/all: 78 tests green (11 new in test/unit/test_leaderboard.py): class and identity from a fixture live tree, nothing identifying in the document, signature verifies with openssl and breaks on a one-byte edit, no private key on the target or in the state, seal omitted cleanly when openssl is missing, factory copy on btrfs and no-op otherwise.
• Installed on 2026-09-14 by bin/omarchy-iso-test --install-only --encrypt (QEMU/KVM, 8 vCPU, 8 GB, encrypted full-disk), then the base image booted and inspected over SSH: timing.sig verifies with the openssl one-liner in the guest and on the host, a one-character edit fails, /var/lib/omarchy/leaderboard/timing.json is byte-identical to the timing log, the @factory copies are identical and the snapshot is back to read-only, and no key or PEM material exists under a leaderboard path on the target. Class recorded as {full_disk, encrypted, kvm, warm}. Same result on top of Speed up installs with compressed qcow2 restores and parallel finalization #145's root-image installer (run 874ca20c).

The class and hardware fields describe how the install was done, so #113 and #145 may need a small follow-up here once they land; the lap-time change in #177 does not.