perf: send only cache misses to the classloader-isolated workers.

[ianbrandt]

Isolating kotlin-metadata to workers means InMemoryCache contents have to cross a classloader boundary. ExplodeJarTask and FindKotlinMagicTask do that by serializing every cache hit into the worker as a JSON seed, which the worker parses back into a deep copy, so a warm cache costs one full copy of the compile classpath analysis per task. This partitions in the daemon instead: hits stay there by reference, the worker receives only the artifacts it has to analyze, and the task merges the two before writing its reports.

On 40 synthetic java-library projects that all declare the same compile classpath, where 68 of the 80 explodeJar tasks have no cache misses at all:

buildHealth, medians of 4 interleaved runs

                 10-jar classpath   14-jar classpath
                     -Xmx4g            -Xmx2560m
  3.17.0              14.0s              37.5s
  main                24.0s              67.5s
  this PR             15.5s              43.5s

3.17.0 is there as the pre-isolation reference. It is the last release that used a noIsolation worker and shared the cache by reference.

A JFR recording attributes the difference. com.squareup.moshi accounts for 82% of the CPU samples that disappear, 1049 down to 639 against a total drop of 500, while com.autonomousapps.internal.asm is unchanged at 80 to 99. So the bytecode analysis is untouched and what goes away is the copying. GC pause time falls from 1054ms to 608ms, about 5% of the wall-clock difference.

The smallest -Xmx that completes drops too, from 640m to 576m on the 10-jar fixture and from 2560m to 2048m on the 14-jar one.

[ianbrandt]

This PR keeps both of the things you flagged in your comment on #1800: artifact.file.absolutePath as the cache key, and the withCoordinates rebind you called a bandaid. I don't think either can go until Coordinates can distinguish two files, so I've kept both confined to the two task actions and their merge helpers. If the classifier gets modelled, the key changes in one place per task and the rebind disappears. I'd be happy to do that follow-up.

[ljacomet]

Yikes, this is not something I was looking at when doing the isolation in #1719, my mistake. The concept of what you are doing here makes sense, thanks for looking into this and improving it. Note that I did not look at the code in detail.

[ianbrandt]

I developed this PR with the help of Claude Code, not having seen the Code of Conduct's strict no-LLM/AI policy. Closing.