fix: reject a negative --limit or --page-size, and correct the docs

[leet-c1]

Description

BREAKING — a negative --limit or --page-size is now a usage error (exit 2), rejected before any request.

--limit is never sent to the API; no list command puts it on the wire. So nothing but c1i could validate it, and --limit -1 silently behaved exactly like the documented --limit 0: every row, exit 0. A negative --page-size did reach the server, costing a round trip to be refused by its range check.

Both are now rejected in rootCmd's PersistentPreRunE, alongside the existing UTF-8 flag check, so every command is covered without a per-command check. The message names what 0 does, since that is what the caller wanted. 0 and positive values are unaffected, and a raw api --query page_size=-1 still goes to the server — --query is raw caller input, not this flag.

The docs needed correcting anyway

The README presented one tenant's measured row counts as general rules, and cmd/agents.md — the doc an agent reads before choosing a batch size — did not mention --page-size at all.

The ~5-row floor is not universal	policies list floors at 6; mcp servers catalog list has no floor. Sizes 1–5 were measured on apps list, users list and policies list — previously only size 1 had been.
A value over the max is not rejected	pageSizeFlag clamps it and sends the max, so an oversized batch silently shrinks.
--page-size 0 is not "no paging"	It means the server's default of 25, verified on six endpoints, and those rows may then overshoot like any other size.

How far a page overshoots varies per endpoint and per size — apps list returned 23 rows at --page-size 10 and 42 at 25, policies list returned 12, users list exactly 10 — so the docs no longer state any figure as a limit.

--limit remains the exact control: enforced client-side per row, so it holds even when a page overshoots.

Guards

Guard 6 pins the agents.md section. Each claim is pinned by phrasings that carry its polarity, so stating the opposite fails the build where a topic word would not — "clamp" is equally present in "does not clamp". It also rejects any row count in that section outside a short allowlist, so a fresh measurement cannot be restated as a limit, and a claim count catches an entry being removed.

Guard 7 pins the new behavior, including through the real command tree — the helper-only tests all passed with the PersistentPreRunE call deleted and the feature inert.

Both were verified to fail when their fix is reverted. README's copy of the contract remains unguarded; that is noted in the test file.

Also

c1i docs agents no longer implies apps get's empty appOwners will fill if you wait — use c1i apps owners <app-id>. The same guidance in apps set-owners --help is unchanged.

cmd/policies_search.go no longer calls the 5-row floor and 0-means-25 "endpoint-specific"; both hold generally, and only that endpoint's lower default is its own.

Release Notes

BREAKING: a negative --limit or --page-size now exits 2 instead of being accepted. --limit -1 previously behaved as unlimited.

Corrected the --page-size documentation: the ~5-row floor is not universal, a value over the max is clamped by c1i rather than rejected, and --page-size 0 uses the server's default of 25. How far a page overshoots varies per endpoint and per size, so no figure in the docs should be read as a limit — --limit N remains the exact control. c1i docs agents now covers this.