morojs: compression middleware on the plain listener only; picks up @morojs/engine 1.1.11

[M-Chris]

One change in the entry, and a dependency that moved underneath it.

frameworks/morojs/app.mjs: the json-comp compression middleware (gzip preferred, brotli available) now sits on the /json/:count route of the plain listener only. The TLS listener is never asked for an encoding (json-tls sends none), so its route carries no middleware and stays on the router's fast path. Same bytes on every profile; json-tls no longer pays for a negotiation it never uses.

Engine: the entry depends on @morojs/moro ^1.8.13, whose range on @morojs/engine now resolves to 1.1.11 at image build. 1.1.11 changes nothing on the wire; its epoll transport makes one epoll_wait per loop turn, and every request is parsed and routed on its own.

[github-actions]

👋 Heads up! This PR modifies the following frameworks:

• varnish → @guillaume.quintard@varnish-software.com

[M-Chris]

Summary of what this PR now carries, and what the all-board run showed.

1. morojs adds the H2 family (baseline-h2, static-h2, baseline-h2c, json-h2c) on @morojs/moro 1.8.15: two extra processes from the same image, :8443 with ALPN h2 and :8082 cleartext prior-knowledge, same one-config-per-process layout as the existing TLS listener. The release fixed Moro's HTTP/2 server for this (it advertised SETTINGS_ENABLE_PUSH=1, which RFC 9113 forbids a server to send and nghttp2 clients reject).

2. scripts/validate.sh: stop the standalone container before the compose stacks. The first two runs of this PR failed only in production-stack, with /api/items/1 answered {"error":"DB not available"} and the four unauthenticated checks getting 500 instead of 401. Cause: when async-db or a compose profile is subscribed, the standalone container runs with --network host and is never stopped, so it is still up when the stacks come up on the same host network. It keeps :8080 bound (with SO_REUSEPORT the kernel splits the proxy's upstream traffic between it and the stack's own server) and, for an entry that also serves H2, :8443 and :8082. The stack's edge cannot bind :8443, every gateway check is answered by the entry's own listener, and production-stack is where it shows, because that listener has no auth and no pool. trillium and trillium-tuned subscribe to both families and pass only because their H2 listener serves the same routes and database.

The change is a 19-line _stop_standalone_for_compose, called at the top of _validate_gateway and _validate_production_stack; a no-op when there is no standalone (GATEWAY_ONLY=true) or it is already stopped, and nothing after that point talks to the standalone (dump_logs reads a stopped container fine). Reproduced locally with meta reduced to async-db + production-stack (same five failures), 18/18 with the fix, full 23-profile run 160/160.

3. Because validate.sh changed, detect validated every enabled entry, and six were red on their own. Four are fixed in this PR, each verified locally:

• varnish: the varnish:9.0.3 image's apt source now also carries 9.1.0, so an unpinned varnish-dev resolves to 9.1.0 and conflicts with the installed 9.0.3 ("you have held broken packages"). varnish-dev is now pinned to the installed varnish version. Image builds end to end.
• humming-bird: the json-tls TLS quality probe failed because NIOSSL's default floor is TLS 1.0. minimumTLSVersion = .tlsv12. 30/30 including the probe.
• aspnet-minimal_caddy and aspnet-minimal_nginx: both Dockerfiles still copied AppData.cs and Models.cs, which feat(aspnet-minimal): Move business logic and types into reusable units #1002 removed from aspnet-minimal in July, so neither has built since. Ported to the current Services/Types layout (DI registrations, AppJsonContext, and the nginx variant's HybridCache routes take the pool from DatabaseService). gateway-h3 12/12; gateway-64 + production-stack 27/27.

Still red and not touched here: vanilla-gateway and vanilla-production. Nothing in them changed since they passed on 2026-10-02, vanilla-epoll (which they build from) passed its own job in this run, and their V toolchain is x86-64-only so I cannot reproduce on this machine. If someone with runner access can share the validate vanilla-gateway group from the job log, I will take it from there.

Happy to split the validator change and the four entry fixes into their own PR if you prefer the morojs change to stand alone.