Resolve Gumbo from JitPack instead of a hand-built local install

[contrasam]

Catalyst depended on com.cajunsystems:gumbo — the coordinate Gumbo's own pom declares, and not one anybody can fetch. JitPack rewrites the groupId to com.github.{owner} when it publishes, so the same jar is com.github.CajunSystems:gumbo once it leaves the build that made it.

The practical consequence: this build resolved only on a machine where someone had run mvn install on a Gumbo checkout by hand, and failed everywhere else with a message that points at Maven Central rather than at the cause.

Measured, not inferred

From a machine with ordinary network access, before and after:

control (com.cajunsystems):
  [ERROR] Could not find artifact com.cajunsystems:gumbo:jar:0.3.0 in central

after (com.github.CajunSystems):
  [INFO] Downloaded from jitpack.io: .../com/github/CajunSystems/gumbo/0.3.0/gumbo-0.3.0.jar (94 kB)
  [INFO] Reactor Summary: 11 modules SUCCESS
  [INFO] Tests run: 9, Failures: 0, Errors: 0 -- in com.cajunsystems.catalyst.gumbo.GumboEventLogTest

Nothing was installed locally for the second run. Other modules' suites also pass on the way through — events 18, core 53, runtime 63, agent 15.

What changed

• pom.xml — added the jitpack.io repository; managed gumbo dependency switched to com.github.CajunSystems
• catalyst-gumbo/pom.xml — same groupId
• Replaced the comment stating that jitpack.io is blocked by egress policy and Gumbo must come from a local install. That was true of one sandboxed environment, not of the delivery mechanism, and had hardened into a property of the build. The new text explains why two coordinates exist, so the next reader doesn't "correct" it back to the one in Gumbo's pom.

Version stays 0.3.0 — Gumbo 0.4.0 is cut but not yet tagged, so it isn't on JitPack. Bumping is a separate change once it is.

Two things for the reviewer

1. The CI bootstrap step is now redundant, and I could not include its removal. .github/workflows/ci.yml clones Gumbo at the pinned tag and mvn installs it before building. That installs com.cajunsystems:gumbo, which nothing references after this change, so the step costs a clone and a build per run and its comment is stale. Removing it is the natural follow-up — I can't push workflow files with the token I have (refusing to allow an OAuth App to create or update workflow ... without workflow scope), so it isn't in this PR.

2. It trades one dependency for another, and that's a real call. The clone-and-install step exists to keep CI deterministic and independent of JitPack availability. Switching coordinates means CI resolves from jitpack.io — a third-party service — on a cache miss; cache: maven is already configured, so it's hit rarely, but it is a new external dependency for the build.

If you'd rather CI not depend on JitPack at all, the alternative is to publish Gumbo under its declared com.cajunsystems coordinate to Maven Central or GitHub Packages. Then the pom's coordinate is the resolvable one, this PR becomes unnecessary, and the ambiguity ends rather than being documented. That's more work and it belongs in Gumbo, not here.

Unrelated, noticed while verifying

catalyst-tools fails 4 tests on macOS — SecureDirectoryStream is unavailable on this platform; refusing plain-path traversal ... from FilesystemTool. That module has no Gumbo dependency and compiles fine; the failure predates this change and reproduces without it. Worth its own issue: on macOS those tests can't pass as written unless they opt into allowInsecureFallback.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR makes Gumbo publicly resolvable through JitPack.

• Adds jitpack.io as an inherited Maven repository.
• Changes managed and module-level Gumbo coordinates to com.github.CajunSystems:gumbo.
• Documents why JitPack and local builds use different group IDs.

Confidence Score: 3/5

The incompatible documented fallback for JitPack-blocked environments should be corrected before merging.

A local Gumbo build installs com.cajunsystems:gumbo, but Catalyst now requires com.github.CajunSystems:gumbo, so users following the existing egress-restricted build instructions still receive a dependency-resolution failure.

Files Needing Attention: pom.xml, catalyst-gumbo/pom.xml, README.md, and CLAUDE.md

Important Files Changed

Filename	Overview
pom.xml	Adds JitPack and changes the managed Gumbo coordinate, but invalidates the repository's documented local-install fallback for blocked environments.
catalyst-gumbo/pom.xml	Updates the module dependency to the JitPack coordinate consistently with dependency management.

_{Reviews (1): Last reviewed commit: "Resolve Gumbo from JitPack instead of a ..." | Re-trigger Greptile}

[greptile-apps]

Local fallback uses wrong coordinate

When jitpack.io is blocked and a developer follows the documented local-install fallback, Gumbo is installed as com.cajunsystems:gumbo while this dependency now requests com.github.CajunSystems:gumbo, causing Maven dependency resolution and the build to fail.