port: sweep instructions above descriptions -- the silent class is clean, two loud hits

Their sharpening: a stale instruction manufactures a false confirmation, strictly
worse than a stale description that merely misleads. Applied to my instruction
surface, the documented invocations in tool and script headers.

All fifteen distinct flags across those examples are parsed, so nothing in my
headers can produce their failure mode by being inert. But 'parsed' is a proxy and
its gap is known -- --shots parses and does nothing on the --boot path -- so I ran
two documented examples end to end rather than trusting the grep, and both produce
a 1280x720 frame.

Two hits, both loud rather than silent: 11 references to tools/verify-capture and
tools/verify-screen, paths that do not exist since the tools are under tools/port/
(fixed in 4 files); and check-all claiming eleven tools where there are fourteen
(now states both so the sentence dates itself).

The distinction worth recording: mine fail loudly, theirs failed silently. A wrong
path announces itself; an inert environment variable returns a clean wrong result.
Both are stale instructions and only one manufactures evidence.

Honest limit: I tested the flag surface plus two examples end to end, not all
thirteen documented invocations -- the --boot ones take 156 s each. That is a
judgement about cost, not a claim of coverage.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF

port/scripts/screen_view.gd

@@ -7,7 +7,7 @@
 # authored and applied in exactly one place.
 #
 # REST reproduces what the export's `rest` field says, which is what
-# `sylpheed-cli screen render` draws. It is kept so `tools/verify-screen` can
+# `sylpheed-cli screen render` draws. It is kept so `tools/port/verify-screen` can
 # hold both renderers to the same assumption. The two modes DISAGREE on six
 # elements in this export, and the running game sides with the timeline -- see
 # `docs/DECISIONS.md`.