fix(cli): reject NUL bytes in message content with byte offset

[santhiprakash]

Summary

buzz messages send and buzz messages edit previously accepted content containing an embedded NUL byte (0x00) and forwarded it through to the relay. The CLI returned accepted:true with whatever the transport preserved, so an agent could believe a complete message was delivered while the relay stored only a truncated prefix.

After validate_content_size, the CLI now rejects any 0x00 byte in the resolved content with a hard CliError::Usage that names the byte offset of the NUL and points operators at the PowerShell literal here-string workaround. The same check runs on both send and edit so a message that was previously published with a NUL-bearing suffix cannot be silently edited into the same shape.

The validator cannot detect the Windows --content $msg class of truncation: the NUL terminates the native command line before buzz.exe starts, so Clap receives only the prefix and the validator never sees the NUL. The error is therefore documented (in code and in the CLI README) as a defense for NULs that reach the process — stdin, file, paste, or non-Windows transports — not a fix for the OS argv boundary itself. The actionable workaround for the Windows case is to pipe the body through stdin using a PowerShell literal here-string (@'...'@) so backtick escapes do not expand to NUL.

Closes #5916

Related issue

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

Testing

. ./bin/activate-hermit
cargo test -p buzz-cli --lib
# 369 passed, 0 failed, 0 ignored (was 363 before; +6 for the new validate_no_nul_bytes tests)
cargo clippy -p buzz-cli --lib --all-targets -- -D warnings
cargo fmt -p buzz-cli --check

Six new unit tests in crates/buzz-cli/src/validate.rs cover:

• accepts normal content (incl. unicode / empty)
• rejects embedded NUL and reports the byte offset
• rejects leading / trailing NUL
• error message names the stdin workaround
• byte offset is measured in bytes (not chars) — a NUL after a 2-byte UTF-8 codepoint reports byte offset 2

No existing tests were modified.