A tiny, zero-dependency client for the Cloudflare REST API v4: attaches a
Bearer token and sends requests over the JDK's `java.net.http` client. It is
the transport the Images product needs — the counterpart to `internal.s3`,
but for Cloudflare's own JSON API rather than S3.

It handles two request-body shapes, both hand-rolled so nothing is pulled in:
a JSON body (`:json <clj-data>`) and a `multipart/form-data` upload
(`:multipart [part …]`). It is stateless and carries no per-product knowledge;
callers build paths and interpret responses.

Just enough JSON to talk to the Cloudflare REST API v4: read the small
`{success, errors, messages, result}` envelopes it returns and write the
compact request bodies (and `x-amz`-free metadata blobs) we send.

This is deliberately *not* a general JSON library — but it is a correct one
for the subset it covers: objects, arrays, strings (with `\uXXXX` and the
usual escapes), numbers (long or double), `true`/`false`/`null`. Keeping it
in-house preserves the library's zero-dependency promise, the same way
`internal.xml` does for S3.

`read` returns objects as maps with *string* keys (Cloudflare's are camelCase,
so callers destructure with `:strs`); `write` accepts maps with string or
keyword keys.

A tiny, zero-dependency S3 client: signs each request with SigV4 and sends it
over the JDK's `java.net.http` client. It is path-style and stateless — just
the transport R2 needs, with no per-operation knowledge baked in.

AWS Signature Version 4 signing, pared down to what R2 needs.

Header-based authorization (not presigned query strings), SHA-256 payload
hashing, path-style URLs. No chunked/streaming signature. The crypto is all
JDK-native (`java.security`, `javax.crypto`), so this carries no dependency.

`sign` is pure — timestamps are passed in rather than read from the clock —
which lets it be checked against AWS's published test vectors.

Just enough XML to talk to S3: pull a tag's text out of a small response
document and build the CompleteMultipartUpload request body.

This is deliberately *not* a general XML library. The documents S3 returns
for the handful of operations we use are small, flat, and machine-generated,
so a tag scan is enough and avoids a parser dependency.