Write run 4's seal: three arms, both legs, both the green and the red branch

Question

What does run 4's seal predict?

What resolving this produces

A sealed prediction document, written before the first dispatch of run 4 and stored off the tracker,
the way run 3's was (~/Desktop/run3-sealed-predictions-2026-09-16.md). Scored afterwards by someone who
did not run it, against the diff, the posted threads and the node artefacts — never against a leg's own
report.

Three arms, decided while charting:

1. Per fix, does the symptom leave the bench? Six precondition tickets, six rows: for each, predict
   whether its symptom is still observable in run 4. A fix that changes nothing observable was fixing
   prose.
2. Which claims are still not derived? Read against the list this ticket is blocked by.
   #487 and
   #488 are the candidates, because both are
   satisfied by "read another file", which is easy to satisfy halfway.
3. What turns up that nobody predicted. Run 3's arm 2 was incomplete and its real finding —
   User2.tsx inventing its own glyph — was on nobody's list. An open arm, scored as "the seal was
   incomplete" if it fills.

Two rules the seal must honour, both broken once already

• It is written before the first dispatch and it covers both legs. Run 3's arm 3 was written at 16:30
  with /specs already dispatched, and the register marks it a weakened seal for exactly that reason.
• It predicts the red branch as well as the green one. #439
  criterion 4 makes a red build open no pull request and end the run cancelled. A seal that predicts
  only green cannot score the outcome that would teach the most.

Not decided

• Whether the per-fix arm predicts a binary (symptom present or absent) or the specific counter value
  (reconcile's fixed, still_present, new). The counters are known by construction on a
  byte-identical commit, so predicting them is arithmetic rather than prediction — but predicting the
  binary loses the case where the counter is right for the wrong reason.
• Where the seal is stored, and how the scorer proves it was sealed before dispatch. Run 3 used a file on
  the maintainer's machine and a timestamp in the register. Nothing verified it.

Start by reading run 3's sealed prediction file, the blocked claims in #487 and #488, and criterion 4 in #439. Review the six precondition tickets, the run register, posted threads, and node artefacts before the first run 4 dispatch. Done means a dated seal covers both green and red outcomes, all three arms, and the unresolved scoring and storage decisions.