Restore the JES2 DDs the STC procedure allocates for its modules

[mgrossmann]

Fixes #256.

The mechanism

A CGI module is dispatched by the MVS LINK SVC into HTTPD's own task. It has
no allocations of its own, so every ddname it opens resolves against the STC
procedure's. That makes samplib/httpd part of the modules' contract, not just
the server's — and c35ab59 removed two DDs from it after checking only
httpd/src/.

mvsMF's jobs API opens the JES2 checkpoint and spool by name, through libc370's
jesopen() (src/jes/jesopen.c:36,46), from three call sites in jobsapi.c:

line	function	endpoint
157	jobListHandler	GET /zosmf/restjobs/jobs
741	do_print_sysout	spool retrieval
1229	find_job_by_name_and_id	single-job lookup

Each answers 500 without the DDs, and writes two console lines per request —
libc370's Unable to open checkpoint dataset DD:HASPCKPT and MVSMF201E. Job
submit is unaffected; jesiropn() dynallocs its own INTRDR.

Verified on the artifacts, not argued

The shipped and the rebuilt samplib XMITs, decoded from CP037:

4.0.0 shipped: //HASP* DD statements = []
4.0.1 new    : //HASP* DD statements = ['//HASPCKPT DD']   (+ HASPACE1, split
                                                            across an XMIT
                                                            record boundary)

make package builds all five modules clean and the archive carries the
corrected member.

Why verbatim, not symbolics

The two lines return exactly as 3.3.x had them. Symbolic volsers would add an
installation parameter that can be got wrong and change the PROC interface in a
patch release; an operator diffing against 3.3.x should find nothing new to get
right. The hardcoded VOL=SER is a real portability problem — the fix for
it is libc370 dynallocating checkpoint and spool the way jesiropn() already
dynallocs the INTRDR. That is a library change and is filed on its own, not
shipped here. The comment tells the installer to check UNIT/VOL=SER against
their JES2 procedure.

Docs

• migration.md was the more severe half — it instructed a working 3.3.x
  system to delete the DDs. Reversed.
• installation.md gains the requirement in the section that already
  explains why a module needs the STC's STEPLIB: same mechanism, one paragraph
  on.
• CLAUDE.md records the failure class — a grep that stops at this repo's
  edge cannot answer "does anything still use this", because four consumer repos
  run inside this address space.

Audit of the neighbouring removals

Same check, re-run against every consumer: stck2tv, httpds_, HTTPJES2,
HTTPDSL across mvsmf/src, httplua/src, httprexx/src — no hits. Those
removals were sound. httplua dynallocs its own DDs, httprexx opens none, and the
procedure's remaining DDs are complete (SYSPRINT/SYSTERM/SYSIN are absent
deliberately — httpstrt.c:47-68 refuses to start if they are allocated).

docs/release-notes/

New. The v4.0.0 Release body, captured before that release is replaced — GitHub
is not a source of record for a body deleted along with its release. The 4.0.1
notes are built from it so the changelog survives the correction.

Not decided here

Two release-mechanics questions for the maintainer, in the issue rather than in
code:

1. THTP400 is already ACCEPTed on any system that installed 4.0.0. A
   4.0.1 full-function SYSMOD under the same FMID cannot simply be received
   over it.
2. Because the samplib is not an SMP element, such a system needs only the
   corrected SAMPLIB(HTTPD) member — not a new SYSMOD at all.

[mgrossmann]

Three corrections pushed in d12e81e. All three were written from one
measurement and generalised — the same move that produced the bug.

The jobs API does not fail uniformly. The description above says all three
call sites answer 500. Only two do:

call site	on an unreachable JES2
jobListHandler (157)	500, REASON_INCORRECT_JES_VSAM_HANDLE
do_print_sysout (741)	500, same
find_job_by_name_and_id (1229)	returns NULL → callers send 404 job not found

The third is the interesting one. find_job_by_name_and_id() returns NULL
whether JES2 is unreachable or the job is genuinely absent, and all four callers
(237, 291, 388, 1783) report the second. A client is told the job does not exist
while it does. The console pair is the only reliable signal, which strengthens
rather than weakens the case for the fix. installation.md and migration.md
now say this.

docs/release-notes/ described a convention the machinery does not
implement. mbt's shared release.yml deletes every existing release for the
tag and recreates it with gh release create --generate-notes, so the body is
built from commit subjects and a hand-written one does not survive a re-push of
the tag. The README now names what actually applies a body — gh release edit --notes-file, after the workflow — and warns that reusing v4.0.0's means
substituting its six artifact names and every HTTPD.V4R0M0.* qualifier.

"Four consumer repos" was three — mvsmf, httplua, httprexx. ftpd is a
separate server, not a module. Fixed in CLAUDE.md and TODO.md, which are the
files now carrying the rule.