[bugfix] Replace CachingResponseWrapper's header-name allowlist with buffer+replay

[duncdrum]

Summary

Stacked on #6691. Supersedes the fixed header-name allowlist that PR added (Content-Length, Content-Type, Last-Modified, ETag, Accept-Ranges) with a structural fix, per design discussion on #6691.

CachingResponseWrapper was conflating two different kinds of header write:

• Pipeline configuration — a controller.xql <exist:set-header> directive, applied by URLRewrite#setHeaders before doRewrite()'s dispatcher.forward() even runs. Must survive regardless of which pipeline step's output eventually wins.
• Step output — anything the dispatched step itself sets (Jetty's own resource metadata, or the step's own XQuery response:set-header() calls). Provisional: if a later <exist:view> step replaces this step's output, its headers must not survive either.

The allowlist from #6691 could only close this gap one enumerated header name at a time. This PR replaces it with a structural distinction instead:

• New HeaderPassthroughResponse interface + HttpResponseWrapper#setPassthroughHeader, used only by URLRewrite#setHeaders, tunneling through however many CachingResponseWrapper layers are stacked to reach the real response immediately. Deliberately distinct from HttpResponseWrapper#setHeader (which backs response:set-header()), so a step's own programmatic header call is not accidentally granted the same bypass.
• Everything else a step writes is now buffered via a sealed BufferedHeader record hierarchy (setHeader/addHeader/setIntHeader/addIntHeader/setDateHeader/addDateHeader) and replayed verbatim, in original order, from flush() — but only for whichever wrapper actually gets flushed.

Content-Type and Content-Length keep their existing special-casing (untouched): Content-Type via the first-write-wins contentType field, Content-Length derived from the actual buffered byte count at flush time rather than trusted from any step's self-reported value.

close #3913

Test Plan

• URLRewriteResponseSetHeaderViewPipelineTest — red against [bugfix] Fix CachingResponseWrapper gaps exposed by the Jetty 12 upgrade #6691's allowlist (an intermediate step's programmatic header leaked through), green after this change.
• URLRewriteFinalStepResponseSetHeaderSurvivesTest — characterization test pinning the case that broke a first attempt at this redesign (a config-only allowlist): a final step's own response:set-header() call, with no static config representation, must still reach the client. Green throughout.
• URLRewriteSetHeaderSurvivesViewPipelineTest (from [bugfix] Fix CachingResponseWrapper gaps exposed by the Jetty 12 upgrade #6691) — config directive survival, green throughout.
• Both original [BUG] URL Rewriting regression with simple pipelines throwing "getOutputStream cannnot be called after getWriter" #6667/[BUG] URL Rewriting regression with simple pipelines returing error 500 like "written x > z content-length" #6669 regression tests still pass.
• Full org.exist.http.urlrewrite suite (25 tests) green.
• Broader org.exist.http.* suite (81 tests) and org.exist.http.servlets.* suite green — no regressions outside the urlrewrite package.

[github-actions]

📊 XQTS result comparison

Comparison of this run against develop.

Metric	develop	this run	Change
➖ Passed	28,846 (90.67%)	28,846 (90.67%)	0 (0.00 pp)
➖ Failures	1,568	1,568	0
➖ Errors	134	134	0
➖ Skipped	1,267	1,267	0
🧪 Total tests	31,815	31,815	0

Relative to develop: 1 newly passing, 1 newly failing, 0 new errors, 0 newly skipped — counting only tests recorded in both runs whose outcome changed.

🔴 Newly failing tests (1)

• Constr-inscope-4 (was passing)

🟢 Newly passing tests (1)

• Constr-inscope-2 (was failing)

_{Runtime: 529.1s (+231.23s vs develop).}

[joewiz]

[This response was prompted by Joe, drafted by Claude Code, and reviewed by Joe.]

Approved. Replacing the allowlist with the config-versus-step-output distinction is the right call — an enumerated list of header names could only ever be closed one name at a time, and the next surface to set an unlisted header would have reopened it. Separating the two kinds of write structurally means the question stops being "which headers are special" and becomes "which step's output won", which is the question that actually determines whether a header should survive. Keeping setPassthroughHeader deliberately distinct from HttpResponseWrapper#setHeader matters too: it would have been easy to grant response:set-header() the same bypass by accident and quietly reintroduce the leak.

The XQTS comparison above is a false alarm — please don't read the −3 as a regression. Constr-inscope-1, -3 and -4 are flaky in the harness, not affected by this change. The same four tests flip in both directions on PRs that cannot possibly affect conformance:

PR	what it changes	Constr-inscope delta
#6687	OASIS catalog wiring	−1, +2
#6666	documentation only	−1
#6661	dependency pinning	−2
#6433	install-and-deploy version handling	−2, +3

A documentation-only PR cannot change XQuery conformance results. I'll open a separate issue for the flakiness with this evidence, since the real cost is the reverse case — a genuine conformance regression getting waved through as "probably the flaky ones again".