Full Changelog 7.1.1 build 0.0.5

ReasonPhraseHttp11Processor.isSupported() reflected only the lookup of Http11Processor.outputBuffer. Had a JDK refused the final-field write, every new processor would have allocated a buffer, copied the filters, caught the exception and kept the stock buffer, while TomcatMultiPortConfig never logged its WARN and left the connectors on the custom protocol - contrary to what findings.md section 6.2 claimed.

The swap is now performed for real on a throwaway processor when the class is initialised (probeSwap); isSupported() returns that outcome and processors skip the attempt entirely when it failed. The probe protocol supplies an HttpParser so an unstarted Http11NioProtocol does not make Tomcat log about a missing one at ACS startup.

ReasonPhraseHttp11ProcessorTest pins it: the probe succeeds on the real field, fails on a field of another type and on null, and a processor from createProcessor() carries a ReasonPhraseOutputBuffer. 15/15 green with JDK 25 and tomcat-embed-core 11.0.22 (javac -proc:full so Lombok runs on JDK 23+).

Docs aligned with the code: findings.md 5.4/6.1/6.2/6.3 (6.2 also states that the tests are not run by the default build-skip-tests profile), README_probe.md no longer suggests a proxy or a container swap, and the CpeAuthChallenge javadoc points at ReasonPhraseOutputBuffer instead of saying the phrase cannot be restored.

A fourth review round rated one gap MEDIUM: an Error from the probe - realistically only a LinkageError when the Tomcat jar on the classpath is not the one the ACS was compiled against - escaped <clinit>, poisoned the class and would have failed the startup through connectorProtocol(), contrary to the documented fail-safe. probeSwap and swapOutputBuffer now catch LinkageError as well, and TomcatMultiPortConfig.reasonPhraseSupported() catches one thrown by the class initialisation itself, logs an ERROR and falls back to the stock protocol. 15/15 green after the change; findings.md 6.2/6.3 updated.