Capture binary HTTP response bodies, and address envelope fields directly

[pinodeca]

Follow-up to #303. That PR made df.http_multipart() able to send real payloads; this one makes df.http() able to receive them, and removes the ceremony around reading a response.

Binary response bodies were being destroyed

Both HTTP activities read the response with reqwest's .text(), which performs a lossy UTF-8 conversion. Any non-textual body — an image, a PDF, an MP3 — came back with every invalid sequence replaced by U+FFFD. The bytes were already gone by the time the envelope was built, so no amount of downstream casting could recover them. A binary response simply could not be stored or forwarded.

Responses are now classified by Content-Type:

• text — carried through unchanged, exactly as before
• base64 — the raw bytes, base64-encoded

The envelope records which happened in a new encoding field. A body counts as text when Content-Type is absent, text/*, a +json / +xml / +yaml suffix type, or one of the common textual application/* types. Everything else is treated as binary.

That default is deliberate: mislabelling text as base64 is recoverable by the user, whereas mislabelling binary as text destroys the data irreversibly. When in doubt, preserve.

Classification and envelope construction moved into a new activities::http_response module so both activities share a single definition instead of maintaining parallel copies.

Envelope fields are now addressable directly

Dot notation previously resolved only against SQL results, which carry a rows array. Reading anything out of an HTTP response therefore required an intervening SQL node purely to destructure JSON:

-- before
df.http(url) |=> 'resp'
~> 'SELECT ($resp::jsonb->>''ok'')::boolean AS ok' |=> 'checked'
~> df.if('$checked.ok', ...)

-- now
df.http(url) |=> 'resp'
~> df.if('$resp.ok', ...)

$resp.status, $resp.body, $resp.ok and $resp.encoding resolve directly. rows still takes precedence, so SQL results behave exactly as before — this is additive, not a change to existing resolution.

Worked example

examples/audio-roundtrip/ exercises the whole path: it sends text to Azure OpenAI text-to-speech, pipes the returned MP3 straight into a Whisper transcription upload with no intermediate table, then verifies the transcript against the original phrase.

It depends on both halves of this work — the MP3 survives only because of binary capture, and it reaches the upload only because data_b64 accepts $speech.body (#303). The form also carries a prompt part whose base64 wraps across lines, which exercises #303's decode fix.

Provisioning and teardown scripts are included; the teardown purges soft-deleted Azure OpenAI accounts, which otherwise keep holding quota.

Testing

• 15 new unit tests covering content-type classification, envelope construction, and envelope field resolution
• E2E tests 2e/2f/2g in tests/e2e/sql/06_http_and_ssrf.sql: a binary response captured and re-uploaded losslessly, envelope field access, and rows precedence
• The example was run end-to-end against live Azure OpenAI: 3/3 phrases round-tripped, all with encoding = base64

Locally: cargo fmt --check clean, clippy adds no new warnings (4 pre-existing in src/lib.rs remain), unit tests 229 passed / 0 failed. I did not complete a local E2E run on this branch — relying on CI for that.

Note on the diff

Docs examples that #303 had to phrase defensively (using a SQL-sourced reference and ($resp::jsonb->>'ok')) revert here to the direct form, since dot notation now exists to support them.