[Java]: Refactor test for better use of matrix

Predecessor: #1917

Successor: #2577

## Problem

The `java-sdk-tests.yml` workflow has two separate jobs — `java-sdk` and `java-sdk-inprocess` — that duplicate ~20 lines of identical setup (checkout, setup-java, setup-node). This duplication makes maintenance harder: action version pin bumps must be applied in two places.

## Proposal

Add a `transport: [default, inprocess]` dimension to the existing `test-jdk` matrix in the `java-sdk` job, and remove the standalone `java-sdk-inprocess` job.

### Matrix shape

```yaml
strategy:
fail-fast: false
matrix:
test-jdk: ["25", "17"]
transport: ["default", "inprocess"]
exclude:
- test-jdk: "17"
transport: "inprocess"
```

The `exclude` prevents the `JDK-17 + inprocess` combination, which is not meaningful (the native library targets a single JDK).

### Conditional step adjustments

- Steps already guarded with `if: matrix.test-jdk == '25'` gain an additional `&& matrix.transport == 'default'` where they should not run for the inprocess leg (e.g., spotless, javadoc, doc-version test).
- The `mvn` invocation switches based on `matrix.transport`: `mvn clean verify -Pinprocess` for inprocess, the existing split build-then-test flow for default.
- Artifact names and test report titles include the transport value for clarity.

### Benefits

- **Less duplication** — shared setup steps defined once.
- **Easier maintenance** — action pin bumps in one place.
- **Consistent naming** — job names like `Java SDK Tests (JDK 25, inprocess)` clearly identify the configuration.

### Risks

- Slightly more complex `if:` conditionals, but manageable given the existing pattern.