Story: Fix image-batch NATS payload overflow, add SVG compression

ores.compute.wrapper already downloads binaries via a plain HTTP GET against the generic S3-like object storage endpoint (ores.http.core/routes/storage_routes.hpp, GET /api/v1/storage/{bucket}/{key}) rather than a NATS request-reply round trip. Bulk binary transfer (many images, each independently addressable by key) is arguably a better fit for that same pattern than for NATS request-reply: no payload-size ceiling to chunk around at all, standard HTTP caching/range-request semantics apply for free, and it sidesteps the batching problem entirely rather than tuning around it.

Leaning towards staying on NATS unless the decision task turns up a good reason not to: NATS itself has no issue with binary payloads (a NATS message is just an opaque byte array), so there's no inherent transport ceiling being fought here. The actual cost stack today is self-inflicted by this app's own wire format, not by NATS or by using request-reply: every message (including image responses) goes through rfl::json::write=/=read (ores.service/messaging/handler_helpers.hpp), so binary SVG data is base64-encoded into a JSON string field – ~33% inflation – on top of being sent fully uncompressed. Sending raw (optionally gzip'd) bytes directly as the NATS payload for image- carrying messages, bypassing JSON/base64 for that field, plausibly removes most of the overflow risk on its own. The decision task should verify this against the synthetic worst case before treating the HTTP- transport migration as necessary – it's a materially bigger change (new storage-addressing scheme for images) that should only be taken on if NATS-with-compression genuinely can't be made to fit.

Decided in the decision task. Measured (not estimated) the actual worst-case batch – the 15 largest SVGs in external/flags/flag-icons/ (the real worst offenders turned out to be Serbia and Ascension Island, not the story's original examples of Norfolk Island/CEFTA, which are both small) – against NATS's actual 1 MiB default max payload (no override configured anywhere in this repo):

The worst case already overflows today, confirming the bug. Gzip compression alone (independent of the base64 question) fixes it with a ~2.5x margin; adding raw-byte encoding on top gets ~3.4x. Neither number comes close to justifying the bigger, riskier HTTP-transport migration (new storage-addressing scheme for images). Both remaining tasks proceed as scoped: compression + raw-byte wire encoding (the load-bearing fix), and byte-size-aware batching (defense-in-depth backstop, not load-bearing given the margin above).

Decided in the compression task. Every NATS message (client and server, request-reply and pub/sub) already funnels through two choke points in ores.nats (make_msg() on send, extract_message() on receive). Added a size-thresholded (4096 bytes), header-flagged (X-Content-Encoding: gzip) compress/decompress pair there instead of in image-specific code – every message above the threshold benefits automatically, with zero changes to ImageCache, ClientManager, or any protocol/domain type, and the mechanism is unit-testable in isolation. This effectively delivers the "compress all NATS messages" capture below as infrastructure, without deciding to spend effort auditing every other message type's traffic patterns – it simply applies wherever a payload happens to be large enough.

Raw-bytes-instead-of-base64 (the compression task's other originally- named mechanism) was descoped as not load-bearing given the 2.5x margin gzip-with-base64 already provides; split into a separate follow-up task.