Fetch Chicory/ASM jars from Maven instead of bundling in gem

[soutaro]

The -java gem bundled the Chicory/ASM jars (~1 MB) under lib/rbs/wasm/jars. This PR declares the dependencies with jar-dependencies requirements instead, so they're fetched from Maven Central at install time — the published gem stays small, everyone resolves the same versions from the canonical source, and conflicting copies can't be loaded at once.

Fixes #3018.

[headius]

This is basically correct but a mess of conflicting comments from the LLM.

• Only the direct dependency jars need to be specified. I believe that's just runtime and compiler.
• Jar specifications are duplicated several places even though the comments claim they should live in the jars source file.
• rbs_jars.rb says it is hand-maintained but other places say it is generated. LLM is getting confused and contradicting itself.

This matches the work I did locally as an experiment, but quite a bit messier with nonsense comments.

[headius]

LLM is making up nonsense, or getting confused...

Renamed jars_dir to local_jars_dir and made it return nil for installed gems (only returns a path when jars are vendored locally for development)

I think in all scenarios jars are downloaded to local .m2 for use, so I'm not sure what this means.

The jars.rb module serves as the single source of truth for jar coordinates, consumed by:

This file does not exist. The actual file, rbs_jars.rb, does seem to be the single source of truth... except its contents get duplicated several other places.

Added graceful error handling for optional AOT compiler jars

Probably no need for this. The WASM interpreter will probably be unusably slow without the compiler, and there's no reason it won't load now.

--

The actual changes to support jar-dependencies look fine but the documentation has a lot of nonsense in it.

[ParadoxV5]

Has this bundled gem degenerated from methodical development to prompt engineering and botsitting?

If the bot cannot do it right, throw its slop out and do it ourselves, and consult human experts rather than a black box of probabilities.

Relying on bot output is not “hand-maintained”; it’s vibed.
And vibe coding is already well infamous for its poor quality and inäbility to learn post-training.

[soutaro]

@ParadoxV5

Fair concern — this PR was a complicated and confused draft, so I understand the reaction.

Either way, I'm responsible for the code that lands here, whether I write it myself, an LLM does, or another contributor does. And I'll be honest: I have almost no JRuby context, and I don't think I could have gotten this one done without the AI's help.

The history is squashed and the misleading description is being rewritten. Thanks for keeping the quality bar high.