`buzz messages get` silently truncates to 50 with no indication; `messages search` hard-caps at 100

This was discovered and reported by my agents, who believe this is unreported so far. My first time posting a bug report. Hope this is helpful

## Summary

`buzz messages get` returns the most recent 50 messages when `--limit` is omitted, with no
error, no warning, and nothing in the JSON to indicate the result is partial. A truncated
history is byte-for-byte indistinguishable from a complete one.

`buzz messages search` has the same shape plus a harder edge: it defaults to 20 and is
capped at 100 regardless of the `--limit` value passed.

This matters most for the CLI's stated audience. `buzz-cli` is described as "agent-first,
JSON in / JSON out, designed for LLM tool calls" — an agent rebuilding context from channel
history has no way to tell that it received a prefix of the conversation, so it reconstructs
a plausible-but-wrong past and acts on it.

## Reproduction

Against a channel with 113 messages, CLI v0.5.9 (bundled with Buzz Desktop 0.5.9, macOS):

```
$ buzz messages get --channel | jq length
50
$ buzz messages get --channel --limit 500 | jq length
113
$ buzz messages get --channel --limit 1000 | jq length
113

$ buzz messages search --query the | jq length
20
$ buzz messages search --query the --limit 500 | jq length
100
$ buzz messages search --query the --limit 150 | jq length
100
```

The 100 on `search` is a cap, not the match count: windowing the same query with `--since`
returns 100 for an early window and 64 for a later one, so more than 100 matches exist.

## Impact — observed, not hypothetical

A team of five agents and one human hit this on 2026-08-11. An agent rebuilt its blocked-work
list from `buzz messages get` reads that were silently cut at 50. Three decisions ruled by the
human earlier that day sat below the cut line. The agent reported all three as still blocking
and awaiting a human ruling; the human, reasonably, believed they had already decided them.
The disagreement took a round of messages and a manual audit to resolve.

No error was raised at any point. The read looked complete.

## Expected

Any of these would prevent it, in rough order of preference:

1. **Say so.** Include truncation in the response — e.g. a `truncated: true` /
`total_available: 113` field in the JSON, and a line on stderr for humans:
`showing 50 of 113 (truncated) — pass --limit`. Correct by construction, costs the caller
nothing, and works for agents and humans alike.
2. **Document the defaults.** `--limit Maximum number of results to return` gives no
hint that a default exists or what it is, and the search cap is not mentioned at all.
3. **Provide a cursor/pagination contract.** `--before` works as a paging key today but is
*inclusive*, so the boundary event repeats on the next page and a naive pager double-counts
it. Either make it exclusive or document the inclusivity.

Raising the default is not the fix — any default truncates something. The problem is silence,
not the number.

## Environment

- Buzz Desktop 0.5.9 (`xyz.block.buzz.app`), bundled `buzz` CLI, macOS 14 (arm64)
- Hosted relay
- Confirmed no workaround via configuration: the CLI reads only `BUZZ_RELAY_URL`,
`BUZZ_PRIVATE_KEY`, `BUZZ_AUTH_TAG` (plus timeout vars). No config file, no limit env var.