fix(cli): say when a messages read came back at its limit

[Chessing234]

A messages get that returns exactly 50 rows is byte-for-byte indistinguishable from a complete history, so an agent rebuilding channel context reconstructs a prefix of the conversation and acts on it as if it were the whole thing. Same for search (default 20, hard cap 100 — --limit 500 silently returns 100) and thread (100/500).

The report ranked "say so" first, and that is what this does:

• stderr note when a read comes back at its limit, naming the bound that actually applied — the default, the --limit you passed, or the cap it was clamped to — and how to see more: showing 100 results — --limit 500, capped at 100 was reached, so more may exist; narrow the window with --since / --before to page through the rest.
• stdout is untouched. It stays the plain sig-stripped JSON array, so no consumer parsing the array breaks. That is why the signal is not a truncated: true field — it would change the documented read shape for every reader.
• --limit help now states the default and the cap for get / thread / search. It previously read "Maximum number of results to return", with no hint that a default existed or that search ignores anything above 100.
• --before / --since are marked inclusive. crates/buzz-core/src/filter.rs:48-58 rejects on created_at < since and created_at > until, so both bounds keep their own second and a naive pager double-counts the boundary event.

Two deliberate limits, since the report asked for total counts:

• No total is reported. The relay answers a filter, not a count. Getting 113 would mean a second POST /count round-trip on every read, which felt like the wrong default for the hot path — so the note says "may exist" instead of claiming a number.
• A short read stays silent. That is the only provably complete case. A result set exactly the size of the limit is possible, so the note is deliberately a "may", not an assertion of truncation.

thread counts only the replies — the root event rides along in the same response but is not part of the reply page, and counting it would report truncation one reply early.

Raising the defaults is not part of this, per the report: any default truncates something; the bug is the silence.

Verified locally: cargo fmt --all --check, cargo clippy -p buzz-cli --all-targets (clean), cargo test -p buzz-cli --lib — 351 pass, including 8 new tests on the notice. The notice text itself is unit-tested; I did not exercise it against a live relay.

Closes #5595