(jsonp,jsr-353) Support embedded binary in Arrays, as already done for Objects

[pjfanning]

Problem

The [issue#5] handling that exposes embedded byte[] as Base64 text was added to _deserializeObject() but never to _deserializeArray(). The same binary value therefore succeeds or fails purely by position:

{"k": <byte[]>}  ->  {"k":"AQID"}
[ <byte[]> ]     ->  MismatchedInputException: Cannot deserialize value of type
                     `jakarta.json.JsonValue` from Embedded Object value

Reproduced with MAPPER.convertValue(Collections.singletonList(bytes), JsonValue.class), and it applies to any VALUE_EMBEDDED_OBJECT reaching an Array — binary formats, TokenBuffer, convertValue.

Fix

Add the matching VALUE_EMBEDDED_OBJECT case to the Array path, including the same fall-through to handleUnexpectedToken() for embedded values that are not byte[]. Applied to both jakarta-jsonp and jsr-353 so the twin modules do not drift again (cf. #92).

Root-level embedded values are deliberately left alone — _deserializeScalar() still reports them as unexpected, carrying its existing // Not sure what to do with it note. That is a separate design question from the Array/Object inconsistency fixed here; happy to fold it in if you want root-level byte[] to become a JsonString too.

Tests

New EmbeddedBinaryTest in both modules (5 cases): binary as an Object value, as an Array value, nested each way, and with JsonArray as the declared target.

⚠️ Note: jsr-353/pom.xml sets <skipTests>true</skipTests>, so only the jakarta-jsonp copy actually runs in CI. I enabled the flag locally to check, and the whole jsr-353 suite errors before reaching any assertion — javax.json.JsonException: Provider org.glassfish.json.JsonProviderImpl not found — which is pre-existing on 3.x and unrelated to this change. The jsr-353 test is included so the modules stay in sync if those tests are ever re-enabled; it does compile.

jakarta-jsonp suite: 28 tests, all green.

[pjfanning]

Follow-up: #97 re-enables the jsr-353 suite (it has run zero tests since Jan 2025 due to the RI's clashing Automatic-Module-Name). I merged the two branches locally to check the interaction — the jsr-353 EmbeddedBinaryTest added here passes once tests actually execute:

[INFO] Running tools.jackson.datatype.jsr353.EmbeddedBinaryTest
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
[INFO] Tests run: 31, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS

So the caveat in the description above ("only the jakarta-jsonp copy actually runs in CI") goes away if #97 lands first. The branches merge cleanly in either order.