Dylib FFI functions can currently accept byte vectors as RVec<u8>, but there is no
way to return one as a Steel bytevector: a returned Vec<u8> goes through
IntoFFIVal for Vec<T> and arrives in Scheme as a list of integers, so bytes-length,
bytes-ref etc. fail on it.

This adds the two missing ergonomic impls:

• From<Vec<u8>> for FFIValue (and From<RVec<u8>>) — returned byte buffers become
  proper FFIValue::ByteVectors
• FromFFIArg<'a> for Vec<u8> — owned-Vec arguments work symmetrically with the
  existing RVec<u8> support

Use case: a Helix plugin's companion dylib streams animation frames (kitty graphics
payloads) to the Steel side as bytevectors. Without this, binary transport needs
base64 strings or per-byte list conversion.

One possible concern: From<Vec<u8>> for FFIValue makes Vec<u8> returns bytevectors
while other Vec<T> returns stay lists — an asymmetry, but the same one Rust itself
has (Vec<u8> is the de-facto byte-buffer type), and it can't break existing code
because Vec<u8> previously satisfied only the list path via IntoFFIVal, which the
blanket impl<T: Into<FFIValue>> IntoFFIVal for T now shadows for this one type.
Reviewer should confirm Matt is comfortable with that override — a returned
Vec<u8> that some existing plugin expected as a list would change type. If that's a
worry, the alternative is a ByteVec newtype instead; happy to rework.

Testing: builds + existing steel-core tests pass on the branch; consumer
(libnothelix) exercises both directions in its animation test suite (316 tests).

🤖 Generated with Claude Code