Accept RACHECK rc=4 (resource not protected) as allowed

[mgrossmann]

Fixes #135. Unblocks mvslovers/libc370#63 — httpd was the last consumer holding it up (ftpd landed its side in fc26874).

The correction to the issue

The issue states httpd "makes no decision on the value — it hands it to CGIs through the HTTPX vector". That is not the case: auth_gate() in src/httppc.c tests != 0 for its RES= route gate, added in 9e7014e (per-route auth policy) a month before the issue was written.

With the documented example from docs/configuration.md:

MOD=MVSMF /zosmf/*  AUTH=BASIC RES=FACILITY:MVSMF.ACCESS

on a system where MVSMF.ACCESS has no profile, RACHECK answers 4 after libc370#63 and every /zosmf/* request gets a 403. So this is an outage in the httpd core, not only a CGI contract question.

What was picked, and why

Option 2 from the issue (normalize 4 → 0 in http_check_auth()), but the deciding argument is not the one the issue gives.

The issue argues for option 2 because runtime-loaded modules make a contract change expensive. That is true in principle but currently hypothetical — grepping mvsmf, httplua, httprexx and every in-tree CGI (httpdsrv.c, httpjes2.c, httpdsl.c) for http_check_auth / HTTPCKAU finds zero consumers. httpd's own auth_gate() is the only caller today.

The load-bearing argument is httpd-specific: http_check_auth() returns -1 for unauthenticated. It was never a SAF pass-through — the published contract is httpd's, not SAF's. And the widened idiom libc370#63 itself suggests, rc <= 4, would read that -1 as allowed and let unauthenticated requests past the gate. Option 1 would have to renumber -1 as well, breaking existing == -1 checks. Option 2 sidesteps it, and because the normalization sits in httpxauth.c, httppc.c is correct unchanged.

rc 4 never means denied (0 permitted, 4 not protected, 8+ refused), so collapsing it into 0 cannot soften a denial.

This also explains why ftpd's opposite choice (ftpd_racf_allowed(), rc == 0 || rc == 4 at the call sites) is not an inconsistency: ftpd calls racf_auth() directly and has no sentinel value in the range.

Changes

• src/httpracf.c + include/httpracf.h — httpracf(rc), the SAF decision table. Free of httpd.h (like httpbody()) so it unit-tests dual host/MVS; 8-char name, no asm alias needed.
• src/httpxauth.c — http_check_auth() normalizes 4 → 0, plus the rationale and a DEBUG trace for the not-protected case (the only place the distinction is still visible).
• src/httppc.c — comment pinning why != 0 is the whole test and must not be relaxed to <= 4.
• include/httpd.h, include/httpcgi.h — the return contract documented at both declaration sites. httpcgi.h is the one CGI authors read.
• test/tstracf.c + project.toml — [[test]] TSTRACF, 12 assertions.
• docs/configuration.md — a RES= resource with no profile permits access; a typo silently disables stage 2 rather than locking the route.

Verification

• make test-host — 4 tests, 63 assertions, all pass (TSTRACF 12/12).
• Regression guard confirmed: reverting httpracf() to the pre-fix rc == 0 makes TSTRACF fail on exactly the rc=4 assertion (11 pass / 1 fail), then passes again restored.
• make (cc370, -Wall -Werror) — clean, all 6 modules link.
• CI green (run 31155461716). Note the shared mbt workflow only runs make deps / make / make test / make lib — make test builds the test load modules, it never executes assertions. The 63 passing assertions above are from a local make test-host.

Not verified on the live MVS system: the end-to-end path still needs libc370#63 to land before rc 4 can actually be observed. This change is safe against both the old and the new library, which is why it goes first.

To verify on MVS after libc370#63 lands

A route with RES= naming an undefined FACILITY profile must serve normally (not 403), and DEBUG 1 should show the rc=4: resource not protected trace for it.

Follow-up

The policy question is deliberately not settled here — whether an undefined RES= profile should mean "everyone passes" is a decision now that httpd can see the difference; today's permissiveness was an accident of the wrong flag bit. Filed separately so this PR stays behaviour-preserving.

Noticed, not touched

include/httpd.h:466 — extern http_set_env(...) is missing its int return type (implicit int, pre-existing). Out of scope here.

[mgrossmann]

Correction to the Verification section above: the build does not pass -Wall -Werror. The actual cc370 invocation is cc370 -O1 -I include ... -c — no warning flags, contrary to what the root CLAUDE.md documents. So "clean" here means the target build compiles and all 6 modules link, not that it is warning-free. Filed as #138, along with the 593 warnings -Wall does surface (one of them a real two-%s/one-argument printf in httpdsl.c:43).

Nothing about this PR's own code changes: it adds no warnings under -Wall either.