Add the sdkharness customer health check (golden path)

[sophiecarreras]

Summary

Adds a versioned .sdkharness/ contract so Backblaze's centralized SDK quality harness can run a customer health check against this repository's own code. One scenario, health/golden-path:

• .sdkharness/tests.tsv: the one contract row (health golden-path simulator ./.sdkharness/tests/run-health).
• .sdkharness/tests/run-health (bash, executable): checks that the target is the loopback simulator (http://127.0.0.1:<port>), drops every ambient B2_* variable except the bucket name, and runs the Java program. It prints exactly one SDKHARNESS_RESULT line.
• .sdkharness/tests/health/GoldenPath.java: a single-file Java program (java -cp "$SDKHARNESS_JAVA_CLASSPATH" GoldenPath.java). It authorizes, uploads a small file, downloads it and compares the bytes, lists it, deletes it, and checks that it is gone. It points the SDK at the simulator with B2ClientConfig.Builder.setMasterUrl, so the requests go to b2api/v2 as they do for customers today. It uses the simulator's fixed test credential only.
• .sdkharness/README.md: what the check can and cannot reach, and how to run it by hand.

No build or source changes. settings.gradle.kts, the Gradle files and core/ and httpclient/ are untouched. The harness builds the core and httpclient jars from the checked-out revision in its own scratch copy and passes them, with their runtime dependencies, as SDKHARNESS_JAVA_CLASSPATH.

One choice to review: the SDK's default HTTP client accepts only https, and the simulator serves plain HTTP on loopback. So the check enables the SDK's own test-server option, HttpClientFactoryImpl.Builder.setSupportInsecureHttp(true). run-health refuses any URL that is not loopback before the program starts.

Verification

• Run through the harness (bin/run-health-checks.sh --target simulator b2-sdk-java) against the pinned standalone simulator (backblaze-labs/b2-simulator at c4e48a1, which accepts b2api/v2). The check was run from this branch at 6b47141, with the jars the harness built from that revision: PASS, with one SDKHARNESS_RESULT health golden-path PASS line.
• Negative control, with the same build and a bucket name that does not exist: FAIL bucket: bucket no-such-bucket not found. The SDK really authorized and listed buckets against the simulator.
• ./gradlew build is unaffected: .sdkharness/ is not in any source set, and check_code only scans src/main.

Merge note

A merge to master runs the existing ci_cd.yml push steps: Upload to b2 (maybe_upload_build_results) and Deploy Javadoc to gh-pages. The Maven deploy steps run only in b2-sdk-java-private. This PR does not change those steps; it only means that merging produces a normal master build upload and Javadoc refresh.

Rollout

Until this merges, the harness records Java health as candidate (not adopted). After it merges, a separate demand-side-ai change promotes the merged revision to active. Java joins the daily Entry Points Testing run only at the end of the Java plan.

Tracking: backblaze-labs/demand-side-ai#1065

🤖 Generated with Claude Code