ISS-6235: record the array-component bypass GHSA-rmj7-2vxq-3g9f, and assert it

[mbryzek]

Closes the GHSA-rmj7-2vxq-3g9f advisory record for this repository.

What this is

A resume. The branch i6235 was already pushed and this pull request already open (no
prior review on it). Merge-on-ready returned conflicts on lib-util#31 at head 8624be2c
and requeued the issue; all four branches on this issue are brought up to date together.
origin/main has been merged in — never rebased — and the conflict is resolved by taking
main's Jackson block. The branch's earlier diff is gone; what is below is what it now
contains.

The advisory is already remediated on main, and the earlier diff was wrong

BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() allowlisted any array on
clazz.isArray() alone and never validated the component type, so a validator configured
to permit arrays admitted an array of a denied class and instantiated its elements with no
further check. Fixed in 2.18.8 and 2.21.4; affected >=2.10.0 <2.18.8 || >=2.19.0 <2.21.4.

Three pull requests landed on main between this branch being cut and this session
(ISS-6227, ISS-6229, ISS-6233) and they pin the entire Jackson family at 2.22.2 through
ThisBuild / dependencyOverrides — out of this advisory's range on both lines. The fleet's
scanner asks sbt what the build resolves rather than parsing build.sbt
(ocaml/lib/security_sbt_dependencies.ml), so a dependencyOverrides pin is exactly what
it reads. The resolved classpath needs no change.

The earlier commit on this branch declared the Jackson artifacts at compile scope so the
floor would reach consumers through the published POM. That is dropped, on two grounds:

1. main's own comment states the opposite decision explicitly and with its reasons — the
   pin "governs THIS build's resolution only … and imposes no floor on a consumer. A consumer
   states its own, as platform and acumen do." Re-litigating a decision recorded in the code
   on a security-sweep branch is not this issue's business.
2. This library imports no Jackson type of its own, so a compile-scope dependency would
   declare a dependency the code does not have.

What this pull request actually changes

The gap main left is documentation and coverage, not resolution — and this repo has a
precedent for closing it, because ISS-6229 did exactly this for the advisory that shares the
same range:

• build.sbt — the floor paragraph named three advisories; it now names four, with the
  array-component bypass stated as behaviour rather than as a version number. The range is
  unchanged: GHSA-rmj7-2vxq-3g9f shares the 2.18.8 / 2.21.4 boundaries GHSA-j3rv-43j4-c7qm
  already set, so the pin does not move.
• JacksonPinSpec — a fifth assertion. It builds a validator with
  allowIfSubTypeIsArray() plus one allowed concrete container, names a denied type as an
  array's component ([Ljava.util.HashMap;), and requires the refusal. A version number
  cannot be read off a classpath at runtime; this can.

Verification

• The new assertion discriminates. Against the pinned 2.22.2 the spec is 5/5 green.
  With jacksonVersion temporarily moved to 2.18.7 (inside the range) it fails, next to
  the generics assertion that shares the range:

  - must apply the PolymorphicTypeValidator to a type id's generic ARGUMENTS … *** FAILED ***
  - must apply the PolymorphicTypeValidator to an array's COMPONENT type … *** FAILED ***
  Tests: succeeded 3, failed 2
  

  The pin was restored before committing; build.sbt still reads 2.22.2.

• Full ci/build.sh clean at the pushed head (the fleet pre-push hook ran it), all tests
  passing.

Decisions & assumptions

• Advisory floor over head-of-line. 2.22.2 is above the advisory's own 2.18.8 floor and is
  what platform and acumen pin, so consumers resolve one Jackson rather than two. Not changed
  here — inherited from main.
• No compile-scope declaration, per the two grounds above. If the POM-floor question is
  worth revisiting it is a policy decision across all four libraries and their consumers, not
  a side effect of a security sweep.
• The advisory record ends up satisfied by main's pin; this pull request is what keeps a
  future regression of that pin from passing silently.

Alternatives considered

• Close these four pull requests as superseded. main already resolves out of range, so
  nothing was strictly owed. Rejected: the pin is the only thing standing between these repos
  and the advisory, and until this change nothing in the repo asserted the array bypass — a
  later bump back onto an affected line would have gone green.
• Bump to the advisory's literal 2.18.8 target. Rejected: it is a floor, not a target, and
  moving down from 2.22.2 would reopen GHSA-r7wm-3cxj-wff9's neighbourhood and split the
  version from what the consumers run.
• Keep the compile-scope declarations and merge them on top of main's overrides. Rejected
  — see "the earlier diff was wrong".

Related

• Advisory record: https://admin.plybk.us/admin/security/advisories/GHSA-rmj7-2vxq-3g9f
• Sibling pull requests on this issue: lib-util#31, lib-ai#61, lib-cipher#33, lib-query#32