messages send: content silently truncated at first NUL byte, still accepted:true (Windows CLI)

## Describe the bug

`buzz messages send` (Windows CLI, `buzz.exe`) **silently truncates message content at the first NUL byte (0x00)** and still returns `{"accepted":true}` — the relay stores only the prefix, with no error and no indication of data loss.

## To Reproduce

On Windows, invoke `buzz.exe messages send` with a `--content` argument containing an embedded NUL byte (e.g. `...codigo ` + 0x00 + `0xc0000005` ...). Rust `OsString`/argv on Windows can carry NUL-free strings only past Win32 `CommandLineToArgvW`, but a NUL inside the argument — produced, for instance, by PowerShell escape sequences — gets the string cut at the C-string boundary when the content is handled as a NUL-terminated string.

Real-world path we hit (agents running goose with `GOOSE_SHELL=powershell`): the model composes a message with Markdown inline code and passes it through a PowerShell **expandable here-string**:

```powershell
$msg = @"
...the crash `0xc0000005` happens by...
"@
buzz messages send --channel --content $msg
```

In an expandable here-string, `` `0 `` is the PowerShell escape for **NUL**. The resulting argument contains a real 0x00 byte, and `buzz.exe` accepts and publishes only the prefix before it:

- Composed content: 2,329 chars
- Relay event content: 466 chars — cut **exactly** at `` `0 ``

Differential validation (messages sent to a test channel and deleted after inspection):

| Here-string | Content sent | Content on relay |
|---|---|---|
| Expandable `@"..."@` with `` `0xc...` `` | ~78 chars | 40 chars — cut at `` `0 `` |
| Literal `@'...'@` (same content) | ~90 chars | 90 chars — complete |

CLI output in both cases: `{"accepted":true,"event_id":"...","message":""}`.

## Expected behavior

At minimum, `buzz messages send` should **fail loudly** (non-zero exit, error JSON) when the resolved `--content` contains a NUL byte — or sanitize/strip it with a warning. `accepted:true` with silently truncated content is the worst outcome: the agent believes the full message was delivered, and no layer (CLI, relay, Desktop UI) surfaces the loss.

Same class of issue as the one we reported in goose (aaif-goose/goose#11259, silently executing only the first line of a multi-line `cmd /C` command): silent truncation anywhere in the send path is much costlier than a hard error.

## Environment

- buzz.exe (Windows, Buzz Desktop install `AppData/Local/Buzz/buzz.exe`), relay wss://rubens.communities.buzz.xyz
- Discovered via Buzz-managed goose agents on 2026-08-14; evidence extracted from goose sessions DB vs relay events, plus controlled send/delete tests on a live channel.

Start at the `buzz messages send` entry point and trace how the Windows `--content` argument reaches the relay, reproducing the issue with a PowerShell expandable here-string containing `` `0 ``. Done means embedded NUL content no longer produces silently truncated data with `accepted:true`; verify either a non-zero error or an explicit sanitization warning.

Written by the indexing model from the issue text.