docs: document the supported Java ceiling and where it comes from

[slayerjain]

Follow-up to #186.

Why

The README's only statement about Java support was "Supported runtimes in CI today are Java 8, 17, and 21" — which is a CI matrix, not a support statement. It said nothing about the highest Java version dynamic dedup can actually handle, and nothing about this repo being part of that limit.

That gap had a cost. Dedup needs both jars to read the app's bytecode:

Component	Role	Reads up to
jacocoagent.jar (k8s-proxy init image)	analyzes coverage	Java 26 (JaCoCo 0.8.15)
keploy-sdk.jar (this repo)	instruments, via ASM shaded through jacoco.core	Java 26 (jacoco.core 0.8.15)

The lower one wins — and while jacoco.core sat on 0.8.12, the lower one was this repo. It capped dedup at Java 22 while the agent could already read more, with nothing anywhere recording that the SDK was the binding constraint.

What exceeding it looks like

Nothing crashes, which is why it's worth writing down. The app is instrumented, the replay runs, every test passes — coverage is just never produced, so no duplicates are found. Indistinguishable from "this app has no duplicates".

What this adds

• A Supported Java versions section: the two-jar ceiling, why this repo is half of it, why exceeding it is silent, and the exact two-repo procedure for raising it.
• A pointer to take JaCoCo's officially supported version rather than the "experimental support for Java N+1" one — the shipped ASM declares one version beyond what it accepts by default, which is exactly how the old Opcodes.V23 note got read one version too high.
• A note that the CI matrix pins the runtimes the sample is exercised on, not the ceiling.

Docs only — no code change.