[Bug] Bazel dependencies are out of sync with Maven; align Bazel BUILD files to pom.xml

**Describe the bug**

The project maintains two parallel build systems — Maven (`pom.xml`) and Bazel (`BUILD.bazel` / `WORKSPACE` / `MODULE.bazel`). Over time the dependency graphs of the two have drifted: some artifacts present in Maven are missing, outdated, or differently versioned in Bazel, which leads to inconsistent classpaths, build failures on the Bazel path, and runtime behavior that differs between the two toolchains.

**Current behavior**

- `pom.xml` declares dependencies / versions / scopes that are not reflected in the corresponding `BUILD.bazel` `deps` / `runtime_deps` / `exports`.
- A few third-party libraries have been bumped in Maven but their `maven_install` / `rules_jvm_external` pins in Bazel still point to older versions.
- New modules added under Maven do not yet have matching `java_library` / `java_binary` targets, or the targets exist but reference a stale dep set.
- Some `provided` / `test` scope mappings in Maven are not mirrored in Bazel (`neverlink = True`, `testonly = True`).

**Expected behavior**

Maven (`pom.xml`) is the source of truth. Bazel BUILD files and the external dependency lock should be regenerated/aligned so that:

1. Every Maven dependency (same `group:artifact:version` and scope semantics) is reachable from the equivalent Bazel target.
2. `maven_install_json` / lock file is regenerated and committed.
3. Per-module `BUILD.bazel` `deps` lists exactly mirror the module's `pom.xml` ``, including `provided` → `neverlink`, `test` → `testonly`, `optional` → not exported.
4. `bazel build //...` and `bazel test //...` succeed and produce the same effective classpath as `mvn -pl dependency:tree`.

**Proposed scope of work**

- Diff every module: `mvn dependency:tree` vs `bazel query 'deps(//module:target)'`, output a reconciliation table.
- Update `MODULE.bazel` / `WORKSPACE` artifact list and regenerate the lock.
- Update each module's `BUILD.bazel` `deps` / `runtime_deps` / `exports` to match.
- Add a CI check (script or Bazel test) that fails when `pom.xml` and `BUILD.bazel` drift again.
- Document the alignment rule in the contributor guide so future PRs touching `pom.xml` must also touch the matching `BUILD.bazel`.

**Acceptance criteria**

- [ ] `bazel build //...` green
- [ ] `bazel test //...` green
- [ ] Dependency diff tool reports zero discrepancies between Maven and Bazel
- [ ] CI guard added to prevent regression

Read the module pom.xml files alongside their BUILD.bazel files, then inspect MODULE.bazel and WORKSPACE. Start by comparing mvn dependency:tree with bazel query 'deps(//module:target)' and record discrepancies. Done means the dependency diff is empty, the lock is regenerated, both Bazel commands pass, and the CI guard prevents future drift.

Written by the indexing model from the issue text.