No on-hardware render check for the two operator-driven states: failed (red) and armed

[louisalexander]

Problem

The end-to-end colour test run on 2026-08-14 drove two real claude
sessions through every hook-driven state and confirmed each one paints
correctly:

Event	State	Colour
SessionStart	idle	#25282D grey
UserPromptSubmit	working	#1256A3 blue
Notification	blocked	#F5A623 amber
Resumed	working	#1256A3 blue
Stop	done	#238636 green
SessionEnd	empty	#000000 black

Two states in config/fleet.json were not reachable by that flow:

• failed (#B42318 red)
• armed (#0A0A0A with amber glyph)

Both are operator-driven rather than hook-driven — they come from
bin/fleet-fail and the arm/confirm path in bin/fleet-press — so no
sequence of agent activity can produce them.

They are not untested: tests/fail.bats and tests/press.bats cover the
state transitions, and tools/demo-row.sh walks a row through every
lifecycle state including these two. What is missing is confirmation that
the real plugin renders them on real hardware the way the hook-driven
states were just confirmed to.

Why it matters

armed is the guard state on destructive teardown (fleet-kill). It is
the one state where a rendering bug is actively dangerous: if armed
is visually indistinguishable from idle on the physical deck, an
operator can confirm a teardown they did not intend to arm. The
non-red-when-armed behaviour was deliberate (6e1c468) and deserves a
hardware check rather than a unit-test check.

failed matters less but is the only red on the deck, and red is the
colour most likely to be mis-tuned against the amber next to it.

Proposed work

• Drive tools/demo-row.sh against the live deck and confirm failed
  and armed are each visually distinct from every neighbouring state,
  in particular armed vs idle and failed vs blocked.
• If the deck is unavailable to whoever picks this up, capture the
  plugin's rendered output instead — plugin/com.louisalexander.flightdeck.sdPlugin/bin/render.js
  produces the key image and can be exercised without hardware.
• Record the result the same way the hook-driven states were recorded, so
  the colour table above can be completed rather than left with two gaps.

Follow-up from the end-to-end test after 587ea72. Low priority relative
to the Notification conflation issue, but worth closing the gap while
the colour work is fresh.