feat(middleware): response-phase modules — request-id + header-transform

[luthermonson]

Two native middleware modules built on the response-phase ABI from ephpm/ephpm #408, plus their cdylib shells and release wiring. One PR to keep the shared files (modules/src/lib.rs, release.yml all_modules, README.md) conflict-free.

ABI pin

Pins ephpm-middleware / ephpm-kv to e63284838d07d348e2155e76916daaf9782c012b — the #408 merge on main, which adds the ResponseMiddleware trait, the declare!(Type, response) arm, and the ResponseView accessors. Deliberately not advanced to #409's scheme/host/body accessors — neither module needs them.

Modules

Module	Phases	What it does
request-id	request + response	Generate or honor an inbound X-Request-Id, inject it for PHP, echo it on the response.
header-transform	request + response	Set request headers PHP sees; set/remove response headers out.

request-id

Request phase resolves the id (trusted inbound if trust_inbound and the value is a safe printable-ASCII token ≤200 bytes, else a generated UUIDv4), injects it as a request-header override for PHP, and stages it as a response header. The response phase fills the header in only when it is still absent (the static-file path runs no request phase) and is idempotent otherwise. The request phase must carry the id itself because the v1 response phase is handed a request view rebuilt from the original inbound headers and cannot see request-phase state — regenerating in the response phase would echo a different id than PHP logged. A trusted-but-malformed inbound id (CR/LF, oversized) is regenerated rather than reflected.

header-transform

request.set / response.set are replace-or-add; response.remove deletes. request.remove and any add are rejected at init rather than silently ignored: the v1 ABI request phase can only override a request header (not delete it), and neither phase has a duplicate-append primitive, so add would equal set. Honest to the ABI, no silent no-ops.

Why no compression module

An earlier revision of this PR included a compression response-phase module; it has been dropped. ePHPm core already compresses buffered responses by default — [server.response] compression is on by default and runs brotli-then-gzip over buffered PHP/static responses (Accept-Encoding negotiation, Vary, Content-Length) before the response phase runs. A middleware compressor would therefore be redundant and inert on a stock server (it would see an existing Content-Encoding and stand down), so shipping one adds surface for no gain. Response-body compression stays a core-server concern; the README documents this explicitly.

Tests / CI

cargo build --workspace (+ --release), cargo test --workspace (98 module unit tests incl. request-phase decisions and response-phase transforms driven through the real ResponseCtx/ResponseView), cargo clippy --workspace --all-targets -- -D warnings, and cargo +nightly fmt --all -- --check all clean locally. Two all_modules entries added to release.yml.