Assert normal address-space termination in the shutdown acceptance test

[mgrossmann]

Summary

Extends tests/shutdown-acceptance.sh (added in #123) to assert that the HTTPD
address space terminates normally after P HTTPD — not merely that the
in-flight crash signatures are absent.

Why

Before the 2026-07-23 libc370 recovery-exit relink (libc370 PR #10, libc370#9),
the crash reproduced as S33E + __CRTGET spam. After the relink those are
gone — but the address space still ends abnormally: an mvsMF poll worker that
ignores quiesce (mvsmf#179) leaves a live subtask, and P HTTPD drives
IEF450I ... ABEND SA03. The pre-existing assertions (S33E / __CRTGET / SVC
dump) pass that run vacuously.

Change

• FAIL on IEF450I ... ABEND and $HASP310 ... TERMINATED AT END OF MEMORY
  (SVC-dump / IEA911E was already covered by the svcdump group, now called
  out explicitly).
• Window-completeness gate: confirm the address-space end was captured
  ($HASP395 ... ENDED or IEF404I, scoped to JOBNAME) before PASS. These
  records appear on clean and abnormal ends, so they gate log-completeness, not
  health — the discriminators are IEF450I / $HASP310 / SVC dump.
• New JOBNAME env var (default HTTPD).
• HTTPD002I / HTTPD060I documented as diagnostic-only, with a CAUTION on a
  PASS that shows none.
• The __CRTGET assertion is unchanged (zero-tolerance) — correct for the
  termination path this test drives; see the note on Shutdown crash: S33E on worker DETACH + recovery ESTAE runs C runtime under a torn-down CRT #122.

Expected state: RED against the current build

With these assertions the test is RED on the current post-relink build,
because of the SA03. That is the correct state: the test now has a genuine
failing condition tied to a specific open issue (mvsmf#179), rather than passing
vacuously. When mvsmf#179 is fixed and this goes green, that is a real signal
that the address space terminates cleanly.

Verification

Exercised against synthetic console logs reproducing the verbatim message lines
from the 11.02 (S33E), 11.35 (SA03), and 2026-07-22 (EOM + IEA911E) runs,
plus a clean-shutdown and a truncated-log case: FAIL on the two crash runs, PASS
on clean, INCONCLUSIVE on the truncated capture, and PASS (via IEF404I alone)
when JES omits $HASP395. The windowed assertion still excludes pre-existing
crash lines. sh -n clean.

Follow-up

The default abend provocation drives the recovery-drain path, not a worker
parked in a long poll, so it does not exercise the SA03 / mvsmf#179 scenario.
A PROVOKE=longpoll mode that does is proposed separately in #126.

Refs #122