v3.28.0 review: the batch failure classification

- A non-ValueError exception from the install run (a card removed
  mid-chain, a transport error) was recorded as a 'skipped' attempt with
  the error text - but the chain had started and died, which is a
  failure.  Only a ValueError (a request/eligibility error: the preset's
  ISD keyset, the plan) is a skip now; anything else is a 'failed' record
  carrying its error.  The PWA's failed row falls back to that error when
  there is no failing step / status word to show.
- The panel's Clear button is disabled while a batch is active (the
  server refuses the clear with 409 anyway) - no pointless error alert.
- api.md and the repo AGENTS document the two outcomes.  Tests: a
  transport error mid-chain is a failure (and the card stays seen), the
  plan's input validation (the block size, a missing cap_hex), the failed
  row without a step, the shared ram_format field, and the Clear state.
  915 frontend + 921 Python; sw cache simple-v438 (unchanged).

docs/api.md

@@ -1163,7 +1163,9 @@ interrupt it; the state lives in memory and a server restart ends the run.
   `phase` is `idle` (no run), `waiting_card`, `installing`, `stopping`,
   `stopped` or `finished`.  A failed attempt carries `failed_step` (e.g.
   `LOAD (3/7)`), `por_sw` (the card's own status word), `por_status`,
-  `por_error` and `sw`; a skipped one carries `reason`.  `current` names the
+  `por_error` and `sw` — or, when the chain died before a verdict (a lost
+  card, a transport error), just `error`; a skipped one carries `reason`
+  (a request/eligibility error: the install never started).  `current` names the
   card being installed (`{iccid, preset, started}`) and `progress` mirrors the
   RAM progress payload while a chain runs.  The report keeps the last 500
   attempts (`attempts_total` counts them all).