Classify pre-JDK 24 Loom pinning as expected

[yschimke]

Summary

• classify BasicLoomTest.testHttpsRequest failures as expected on JDK 21–23
• keep the same failure unexpected on JDK 24+, where JEP 491 should prevent monitor-based pinning
• update the Gradle commentary and status-site documentation to describe the version-aware result

Why

On JDK 21–23, Http2Connection.newStream holds intrinsic monitors while Http2Writer.flush performs a potentially blocking write. A virtual thread that blocks there pins its carrier. JEP 491 changes this behavior starting in JDK 24, so the existing status collector should distinguish the predicted older-JDK failure from a regression on newer JDKs.

This keeps the original assertion intact and preserves the JUnit evidence while presenting the known pre-JDK-24 result as expected rather than as an unpredicted finding.

Verification

• exercised the result classifier for JDK 21, 23, 24, and 25, plus the existing ECH expected-failure path
• node --test site/assets/finding-groups.test.js
• ./gradlew containers:compileTestKotlin
• git diff --check