Grouped dependency updates (#15-#19) on top of the org.json linkage fix

[jochen-testingbot]

Groups the five open dependabot PRs into one branch so they are tested together, on top of the
linkage fix from #14.

Contents

Commit	Replaces
Fix NoClassDefFoundError: org/json/JSONException at runtime	#14
Bump org.jenkins-ci.plugins:plugin 6.2211.v27f680c93c53 -> 6.2221.va_045130417c9	#19
Bump io.jenkins.tools.bom:bom-2.541.x 6699.v4f03a_ff2f9c2 -> 6815.v1fb_2a_fee3765	#16
Bump actions/checkout 7.0.0 -> 7.0.1	#18
Bump actions/setup-java 5.5.0 -> 5.7.0	#17
Bump jenkins-infra maven-cd.yml 1.8.3 -> 1.8.4	#15

Each bump is byte-identical to its dependabot PR, including the pinned commit SHAs.

Why grouped, and why on top of #14

The dependabot PRs were each opened against master, so their CI ran without the guards #14 adds
(PluginLinkageIT and hpi.strictBundledArtifacts). Stacking them here means the bumps are validated
by those checks rather than landing beside them untested.

That matters most for the BOM bump. Before #14, the org.json linkage depended on a transitive plugin
chain (junit -> echarts-api -> jackson2-api -> json-api), and a BOM bump is exactly the kind of
change that reshuffles those versions. With the dependency declared directly it can no longer break
that way — this PR is the first evidence of that holding.

Verification

mvn clean verify green: 35 unit tests + 3 integration tests. Specifically after the bumps:

• the bundled jar set is unchanged, so hpi.strictBundledArtifacts does not trip;
• PluginLinkageIT passes — no package moved out from under a declared dependency;
• json-api and apache-httpcomponents-client-4-api still resolve to the same versions.

Not verified on a live Jenkins. The NoClassDefFoundError path from #14 still deserves a Test
Publisher smoke test on a real instance before this is released.

Merging

This supersedes #14 and #15-#19; all six can be closed once this lands.