Add eight sdkharness conformance checks: file operations and bucket CRUD

[sophiecarreras]

Summary

Adds eight conformance scenarios to the .sdkharness/ contract (health is unchanged), so Backblaze's SDK quality harness can ask whether this SDK really does what its capability card claims. This is the first slice: the core file and bucket operations.

• .sdkharness/tests.tsv: eight rows, conformance <capability> simulator ./.sdkharness/tests/run-conformance, for files.upload, files.download_content, files.download_by_id, files.list, files.delete_version, files.hide, files.metadata and bucket.crud.
• .sdkharness/tests/run-conformance (bash, executable): same guards as run-health (loopback simulator URL only, every ambient B2_* dropped, fixed test credential). It compiles conformance/Support.java and the scenario's class with javac --release 11 against the jars the harness built, runs it, and prints one SDKHARNESS_RESULT line. A JDK 11 single-file launch cannot import a second source file, which is why the shared helper is compiled rather than imported.
• .sdkharness/tests/conformance/*.java: one program per scenario, using only the SDK's public API. Each one cites the B2 API pages its assertions come from, makes its own sdkharness-conf-* buckets, and deletes everything it created, on failure too.
• .sdkharness/README.md: what each scenario asserts and how to run one by hand.

files.metadata is partial on the card (by name is emulated with an HTTP HEAD of the download URL). The check records the SDK's own HTTP requests and asserts that boundary: by id is a POST to b2_get_file_info, by name is a HEAD of /file/<bucket>/<name>.

No build or source changes. The Gradle files, core/ and httpclient/ are untouched, and .sdkharness/ is in no source set. There is no test in this repository that pins the contract file.

Verification

Run through the harness adapter against the pinned standalone simulator (backblaze-labs/b2-simulator at 21a4002), with the jars the harness built from this branch's revision, under a JDK 17 launcher (and the wrapper by hand under JDK 11 for files.list, files.metadata, bucket.crud):

Scenario	Result
files.download_content, files.download_by_id, files.list, files.delete_version, files.hide, bucket.crud, files.metadata	PASS
files.upload	FAIL, unusual name: a file named st/upload/sp ace/... comes back as st/upload/sp+ace/...

The files.upload failure is a finding, not a loosened check. B2 documents X-Bz-File-Name as "percent-encoded UTF-8. For example, spaces should be replaced with %20" (b2_upload_file). B2StringUtil.urlEncode is URLEncoder.encode(s, UTF8).replace("%2F", "/"), which writes a space as +, so the stored name contains a literal plus. The other legs of files.upload (size, sha1, content type, fileInfo, listing, byte-identical download, empty file) pass before that leg runs. Whether to change the encoding is the maintainers' call; the check will go green when it does.

./gradlew build is unaffected by this change.

Merge note

A merge to master runs the existing ci_cd.yml push steps (upload to b2, Javadoc to gh-pages); this PR does not change them.

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