Headless: refuse a run that can't honour an explicit --disable-hle

When the firmware module a --disable-hle bit asks for is neither installed nor
on the disc, that library silently runs our HLE instead. For the emulator that
is the right thing; for a test tool it means the run measures something other
than what was asked for and says so only as one INFO line, which is easy to
grep past and easy to never see. It cost a round of wrong results here, where
the memory stick headless defaults to (beside the exe, not the app's) had no
firmware, so a comparison against the real mpeg.prx was quietly a comparison
against the HLE it was supposed to be measured against.

g_unavailableDisableFlags already records exactly which flags fell back, so it
just needed an accessor. Headless now names each one, prints the flash0:/kd and
memory stick it looked in, and fails the run.

Only an explicit --disable-hle binds. sceMpeg and sceMp4 are LLE by default, and
falling back is the correct and expected behaviour wherever no firmware is
installed - making that fatal would fail every run on such a machine.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

docs/debugging.md

@@ -171,6 +171,13 @@ produced a round of bogus results here:
 The last three compound: the fix is to treat the run's exit code and a positive "we got here" counter as
 preconditions, and only then believe the error counts.
 
+For the silent-fallback half of this, headless refuses the run rather than substituting: an explicit
+`--disable-hle=` whose firmware module isn't there names the module, prints the `flash0:/kd` and memory stick
+it looked in (usually enough to spot that it's the one beside the exe), and exits 1. Only an *explicit*
+`--disable-hle` binds - sceMpeg and sceMp4 are LLE by default and still fall back quietly, or every run on a
+machine with no firmware would fail. So when a measurement depends on the real module, pass the flag
+explicitly even though it's on by default, and the run will tell you if it didn't get it.
+
 ## Debugging and breakpoint considerations
 
 It might be worth trying the interpreter - all types of breakpoints are the most reliable with this CPU backend.