security(deps): close 4 of 6 Maven alerts — jsoup, jose4j, and remove unused htmlunit

[jcschaff]

Closes 4 of the 6 Maven Dependabot alerts, including the only critical one. From the triage
in #2016.

package	change	module	alerts closed
org.jsoup:jsoup	1.15.2 → 1.23.1	vcell-cli	2 medium
org.bitbucket.b_c:jose4j	0.9.3 → 0.9.6	managed in root pom	1 high, 1 medium
net.sourceforge.htmlunit:htmlunit	removed	vcell-rest	1 critical

Two of these were not one-line bumps

htmlunit was removed, not bumped. It is scope=test and referenced by no .java anywhere
in the repo — dead weight. And 2.70.0 → 3.0.0 renames the groupId
(net.sourceforge.htmlunit → org.htmlunit), so a "bump" would be a migration for a dependency
nothing uses. Worth noting what this means for the alert banner: the repo's only critical Maven
alert was never in shipped code — it was a headless browser for tests.

jose4j needed managing, not bumping. vcell-server declares it directly, while vcell-rest
also receives it transitively from quarkus-oidc → smallrye-jwt, which pins 0.9.3 in Quarkus
3.5.2:

+-vcell-rest
  +-quarkus-oidc → smallrye-jwt → jose4j 0.9.3
  +-vcell-server                → jose4j 0.9.6      ← raising only this side

Raising one side made the paths disagree and failed the enforcer's DependencyConvergence rule.
It is now pinned once in the root pom's dependencyManagement behind a jose4j.version property —
the single point both paths resolve through.

The comment in the pom says this, and it matters: that override should be removed, not raised,
when the Quarkus upgrade lands and pins a newer jose4j itself.

Deliberately not included: woodstox-core

The remaining medium alert (woodstox-core 5.0.1 → 5.4.0) collides the same way but cannot be
managed away safely:

jsbml-core → staxmate 2.3.0 → stax2-api 3.1.4
woodstox-core 5.4.0        → stax2-api 4.2

stax2-api is pinned nowhere, and 5.0.1 happened to bring 3.1.4 — which is why it converged
before. Forcing 4.x under staxmate 2.3.0 risks a runtime break in XML parsing, and no compile
error would catch it: woodstox is a StAX provider resolved by ServiceLoader, which is why
nothing imports it and why the existing pom already excludes it from jsbml-core and re-declares
it at a pinned version.

For a medium DoS advisory that trade is not obviously worth it, so it is left for its own change
with that analysis rather than smuggled in here. Recorded in #2016.

Verification

• Full reactor compile test-compile across vcell-core, vcell-server, vcell-cli,
  vcell-rest — BUILD SUCCESS, which also proves the htmlunit removal breaks no test sources.
• Resolved versions read back with dependency:list rather than assumed:

org.jsoup:jsoup:jar:1.23.1:compile
org.bitbucket.b_c:jose4j:jar:0.9.6:compile
com.fasterxml.woodstox:woodstox-core:jar:5.0.1   (unchanged, as intended)
org.codehaus.woodstox:stax2-api:jar:3.1.4        (unchanged, as intended)
htmlunit                                          (absent)

After this, the Maven portion of the alert banner goes from 6 to 1, and that one is the documented
woodstox case.

Refs #2016

🤖 Generated with Claude Code

https://claude.ai/code/session_018kr8SbzXtwW3gMVUgMfDDt