fix: Read file-like KVS values before upload and reject unencodable ones

[vdusek]

Passing a file-like value (open(...), io.BytesIO(...)) to set_record — or to actor.start / actor.call / actor.validate_input / run.metamorph via run_input — crashed with a raw TypeError: 'BytesIO' object is not an instance of 'Sequence'. encode_key_value_store_record_value set a content type for io.IOBase but passed the object through unread, and impit's content= only accepts bytes-like bodies.

The encoder now reads file-like values into memory. Detection is duck-typed on a callable read, so non-io.IOBase wrappers work too. Binary maps to application/octet-stream, text to text/plain. read() is called with no arguments, so the value is consumed from its current position and the object is neither rewound nor closed.

Values it cannot turn into a body now raise TypeError instead of reaching the transport:

• async file-likes (aiofiles, Starlette UploadFile) — read() returns a coroutine
• read() returning neither bytes nor str, e.g. None from a non-blocking raw stream
• a non-bytes-like value with a non-JSON content type, e.g. set_record('k', {'a': 1}, content_type='image/png')

Note: impit exposes no streaming content= API, so uploads are fully buffered rather than streamed.

Tests: set_record over BytesIO / StringIO / a duck-typed reader, sync and async, over both compression algorithms, plus encoder coverage of the three rejection paths.

✍️ Drafted by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.65%. Comparing base (77c4ea6) to head (8c081d6).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #965      +/-   ##
==========================================
- Coverage   94.66%   94.65%   -0.01%     
==========================================
  Files          58       58              
  Lines        5248     5259      +11     
==========================================
+ Hits         4968     4978      +10     
- Misses        280      281       +1     

Flag	Coverage Δ
integration	92.45% <46.66%> (-0.12%)	⬇️
unit	84.04% <100.00%> (+0.14%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Pijukatel]

asyncio.to_thread is useful only to the branch that can do IO. It just adds overhead in other cases, or? So it improves the less frequent case at the cost of the main use case

[vdusek]

Well, AFAIK the criterion is more whether the callee releases the GIL. If it does, the worker thread can work on the offloaded task, while the main thread, which runs the event loop, can run other asyncio tasks.

And here is the problem: json.dumps, which is called in encode_key_value_store_record_value, never releases the GIL. So yeah, let's remove it.

Thanks.