docs(cloudflare): explain edge compression and the agent.md gap (#195)

## Summary

Adds a **Response Compression** section to `docs/cloudflare.md` covering
two things an operator otherwise has to reverse-engineer:

1. why the Worker does not compress in the application (Cloudflare
compresses on egress, and `encodeBody` defaults to `"automatic"`, so an
application-compressed body gets encoded twice), while Node deployments
still do
2. that `/api/actions/:actionId/agent.md` is served uncompressed,
because Cloudflare's default compressible content types list
`text/x-markdown` but not the `text/markdown` this endpoint returns

## Why not just change the content type

`text/markdown` is the registered type from [RFC
7763](https://www.rfc-editor.org/rfc/rfc7763.html); `text/x-markdown` is
the pre-registration legacy spelling. Switching the response to the
legacy type purely to match one CDN's list would make the API less
correct for every deployment.

The payoff would also be small. Measured across all 11,181 actions in
the generated catalog:

| | raw | gzip |
|---|---|---|
| median agent guide | 1.5 KiB | — |
| mean | 1.8 KiB | — |
| largest (`alpha_vantage.get_technical_indicator`) | 19.9 KiB | 1.7 KiB
|

So the doc says what the behavior is and points at the Compression Rule
that changes it, and leaves the wire format alone.

## Depends on #193

The first paragraph describes the Worker leaving compression to the
edge, which is what #193 implements. **Merge after #193.** Until then
`main` still runs Hono's `compress()` on Workers, which is the bug #193
fixes.

## Validation

- `oxfmt --check .` clean
- docs-only change; no code, no tests affected

Author: BlackHole1

docs/cloudflare.md

@@ -153,6 +153,25 @@ cleaned up automatically. Workers KV applies the configured TTL when each file i
 deletes it automatically. KV clamps `OOMOL_CONNECT_TRANSIT_FILE_TTL_SECONDS` to a minimum of 60
 seconds and `OOMOL_CONNECT_TRANSIT_FILE_MAX_BYTES` to a maximum of 25 MiB.
 
+## Response Compression
+
+Cloudflare negotiates and applies response compression on egress, so the Worker leaves compression
+to the edge instead of running it in the application. Workers build responses with `encodeBody` set
+to `"automatic"`, which means the runtime encodes the body itself to satisfy the `Content-Encoding`
+header; a body the application had already compressed would be encoded a second time and arrive
+undecodable. Node deployments have no edge in front of them and keep compressing in the application.
+
+[Cloudflare's default compressible content types][cf-compression] include `application/json`, so
+eligible `/api` and `/v1` metadata responses are compressed for clients that advertise support.
+Eligibility also requires a `200` status and a body of at least 48 bytes for gzip or 50 bytes for
+Brotli and Zstandard, so the smallest responses stay uncompressed whatever their content type. The
+list has `text/x-markdown` but not `text/markdown`, which `/api/actions/:actionId/agent.md` returns,
+so agent guides are served uncompressed. They are small — around 1.5 KiB for a typical action and
+20 KiB for the largest one in the catalog — so this is usually not worth acting on. Add a
+Compression Rule matching `text/markdown` if your deployment serves agent guides heavily.
+
+[cf-compression]: https://developers.cloudflare.com/speed/optimization/content/compression/
+
 ## Configuration
 
 Cloudflare uses the same environment variable names for origin, auth tokens, action policy, transit