Byte-safe REST payloads for exec and file routes

## Problem

JSON routes on the public HTTP API turn arbitrary bytes into lossy UTF-8:

- `/vms/{id}/exec` and `/run` return `stdout`/`stderr` as `String` (`crates/capsem-service/src/vm_files.rs`, `crates/capsem-api/src/execution.rs`), so binary output is corrupted.
- `/vms/{id}/files/read` returns `String`.
- `/vms/{id}/files/write` accepts `content: String` (there is an open TODO in `crates/capsem-api/src/files.rs`).

Only `/vms/{id}/files/content` carries raw `application/octet-stream`.

## Outcome

Byte-exact REST payloads. Either:

- use the existing raw-body route for file content and an explicit encoding field for exec output, or
- steer byte-oriented clients to the `capsem.stream.v1` stream API from #207.

This changes the public contract and SDK types, so it has to be sequenced with #199 (typed SDKs) and include a migration note.

## Depends on

#207, #199.

Start by reading crates/capsem-service/src/vm_files.rs, crates/capsem-api/src/execution.rs, and crates/capsem-api/src/files.rs, including the open write-content TODO. Review #207 and #199 before choosing how the exec and file routes should represent arbitrary bytes. Done means byte-exact REST payloads, aligned SDK types, and a migration note for the changed public contract.

Written by the indexing model from the issue text.