fix(cli): say when dms, notes, feed, social and workflow reads come back at their limit

[Chessing234]

Refs #5595 — the rest of the read commands.

Stacked on #5721. It reuses effective_limit / truncation_notice, which that PR introduces, so its two commits are in this branch's history and the diff here is the eight commits above them. Please merge #5721 first, or say the word and I will fold this into it.

#5721 made messages get, search and thread say when a read came back at its bound. Every other list-shaped read has the same shape and the same failure: a full page is byte-for-byte a complete answer, so an agent enumerating conversations, notes, feed entries or workflow runs treats a prefix as the whole set.

• refactor: the two helpers move out of commands/messages.rs into limits.rs — they were never message-specific, and a sibling command should not have to import from another command module to use them.
• then one commit each for dms list (50/200), notes ls (50/200), feed get (20/50 — the tightest bounds here, and the read most likely to hit them), social notes (50/100) and workflows runs (20/100).
• --limit help on those flags now names the default and the cap, which previously read "Maximum number of results to return" with no hint that either existed. notes ls already documented its bounds and is unchanged.

stdout is untouched everywhere: the note goes to stderr, so nothing parsing the JSON array changes. social notes prints the relay response verbatim, so it parses the response back to count what arrived rather than assuming the page was full.

Verified locally with CI's own gates: cargo clippy --workspace --all-targets -- -D warnings clean, cargo fmt --all --check clean, cargo test -p buzz-cli --lib (363, 6 new on the shared helper).

[themiguelamador]

Requesting changes for two correctness issues found across the full PR diff.

• P1 — The hard-cap recovery instruction names flags most commands do not have. The shared notice universally tells users to page with --since / --before, but dms list, messages thread, notes ls, and workflows runs expose neither flag; feed get and messages search only expose --since, which cannot retrieve older results. Those commands therefore direct an agent into rejected or ineffective follow-up calls precisely when data may be missing. messages get now advertises only its real timestamp-window narrowing, social notes advertises its composite --before + --before-id cursor, and commands without a usable older-page mechanism say that they cannot request a larger page.
• P2 — social notes silently suppresses the truncation warning on malformed relay JSON. It printed the raw body, parsed with unwrap_or(0), and treated any non-array response as zero results. That both emits invalid machine-readable output and makes a full/unknown response appear safely short. The command now validates the event array before writing stdout and returns a clear CLI error when it cannot determine the result count.

Fix: 589753e2b (review/pr-5934-fix).

Verification:

• cargo test -p buzz-cli --lib — 364 passed
• focused truncation helper/message tests — 15 passed
• cargo clippy -p buzz-cli --all-targets -- -D warnings
• cargo fmt --all
• git diff --check

[Chessing234]

Thanks — both fixed, in 0d1b882 (P1) and 1fe89fc (P2). Complear/buzz 404s for me, so 589753e2b was unreachable and these are written from your description.

P1 — advice that names real flags. You are right that the shared notice was worse than useless on most of these commands. Each read now declares its contract once, as a ReadLimits { default, max, paging }, and Paging is what the notice reads at the cap:

command	flags it really has	Paging
messages get	--since, --before	TimestampWindow
social notes	--before, --before-id	BeforeCursor
feed get, messages search	--since only	SinceOnly
dms list, notes ls, messages thread, workflows runs	neither	None

SinceOnly says "--since only narrows to newer results — this command cannot request an older page"; None says "this command has no windowing flags — it cannot request a larger page". Below the cap all four still say "pass a larger --limit", which is true regardless of paging, and there is a test asserting exactly that. The negative assertions matter as much as the positive ones, so the tests also check the None and SinceOnly notices contain no --before at all.

Replacing the loose (returned, requested, default, max) argument list with the struct is deliberate: the paging kind belongs with the numbers, and a fifth positional u32-adjacent argument is a transposition waiting to happen.

P2 — social notes on an uncountable body. Now parsed before anything reaches stdout, by count_events, which requires a JSON array whose every element is an object; anything else is a CliError saying the result count is unknown. One thing I tightened beyond the description: serde_json::from_str::<Vec<Value>> alone accepts ["a","b"], so the element check is what actually makes it a validation rather than a parse.

Verified on the pushed head: cargo test -p buzz-cli --lib 369 passed (was 364; the new cases cover each Paging variant at and below the cap, and the uncountable bodies), cargo clippy -p buzz-cli --all-targets -- -D warnings clean, cargo fmt --all -- --check, git diff --check.