tests/e2e: say when the CODE failed, not just which properties are missing

CI has been red on the Quantum ESPRESSO case, reporting

    ok    code ran and produced output
    FAIL  TE extracted
    FAIL  STRESS extracted
    FAIL  PRESSURE extracted

which reads exactly like a parsing bug and is not one.  The suite only
checked that the output FILE existed, and for a code whose output is its
stdout the harness writes that file itself -- so it exists however badly
the run went, and the first check passes no matter what.

Now a non-zero exit fails the case immediately, quoting the code's own
last words, and says in as many words that the properties below are
missing because of that rather than because of the parsers.  For a
stdout code the diagnostic is in the output file rather than stderr, so
it falls back to reading it.

This does not fix the QE failure, which does not reproduce here: niobium
and CI run the same QE 6.7 and the same sssp pseudopotential package to
within a Debian revision, so whatever differs is not visible from the
current log.  The next CI run will state its own reason, which is the
point.

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

Author: andy

tests/e2e/run_tests.py

@@ -117,6 +117,32 @@ def run_case(case, verbose, keep, required=()):
             report.check(False, 'code produced %s (exit %d) %s'
                          % (case['output'], rc, err.strip()[:300]))
             return report
+
+        #  A code that exits non-zero has failed, and every property
+        #  after this point will be missing for that reason and not
+        #  because anything is wrong with the parsers.  Reported here,
+        #  with the code's own last words, because the alternative --
+        #  which this suite did for a while -- is a list of absent
+        #  properties that reads exactly like a parsing bug.
+        #
+        #  The message matters more than the check: for a code whose
+        #  output IS its stdout, the file exists no matter how badly the
+        #  run went, so the diagnostic is in the file rather than stderr.
+        if rc != 0:
+            detail = err.strip()
+            if not detail:
+                try:
+                    detail = open(job_out, errors='replace').read()
+                except IOError:
+                    detail = ''
+            tail = [l for l in detail.splitlines() if l.strip()][-12:]
+            report.check(False,
+                         'the code itself failed (exit %d) -- every property '
+                         'below is missing because of that, not because of '
+                         'the parsers:\n        %s'
+                         % (rc, '\n        '.join(tail)))
+            return report
+
         report.check(True, 'code ran and produced output')
 
         # --- stage 2: the real monitor --------------------------------