feat: reject known-bad arguments locally, before the API round-trips

[arch-colony]

Extends the guard family started by _require_uuid and _validate_totp_code: catch, at the call site, the arguments the server is documented (or tested) to reject — so the caller gets a clear local error and no wasted round-trip.

No version bump (per request).

The safety case

Every guard rejects only values the API already refuses, so none can turn away input the server would have accepted. That is asserted two ways for each:

• unit: the validator accepts every valid value and rejects the specific bad ones;
• method-level: a bad argument raises before any HTTP request — a mocked transport that must stay assert_not_called(). Validation that fired after the request would be pointless, so the test enforces that it fires before.

Guards added (evidence cited in each docstring)

Guard	Methods	Contract & evidence
_require_nonempty	create_post (title+body), create_comment, update_comment, send_message, search	Empty/whitespace → 422 string_too_short. create_post title & body confirmed against the live API (empty → 422 on each); the rest are unambiguous required fields. Does not enforce longer documented minimums (search's 2 chars) — a 1-char value is plausible and the server owns that floor.
_validate_vote_value	vote_post, vote_comment	{-1, 1} only — no clear-vote semantic; 0, 2, -2 all 422, per tests/integration/test_voting.py. bool rejected (serialises to true, which the server refuses). 1.0 passes (server may coerce; not newly rejected).
_validate_reaction	react_post, react_comment	Documented 8-key set, with a targeted hint for the exact mistake the docstrings warn about — passing the Unicode emoji instead of its key.
empty-list check	vote_poll	option_ids=[] isn't None, so it slipped the existing guard and sent {"option_ids": []} (422). Now caught.
period check	subscribe_premium	{monthly, annual} — the docstring already documents 400 INVALID_INPUT otherwise.

Validators live in client.py and are imported by async_client.py, so sync and async share one source of truth (as they already do for _require_uuid).

Deliberately NOT added — false-validation risk

• post_type / sort enums — high value, but a drift risk; the codebase already made colony slugs permissive on purpose for exactly this reason.
• pagination limit/per_page — commonly clamped server-side, not rejected; a local range check would raise on input the API accepts.
• register(username) — the charset/length pattern is documented nowhere, so any rule would be a guess.

These are noted as follow-ups pending a confirmed reject-vs-accept contract.

Verification

• 52 new tests; full unit suite 1059 passed, 1 skipped; ruff clean.
• Mutation-tested: breaking any one validator turns the suite red — verified applied by sha256 before/after (an unapplied mutation reports identically to a survived one), teardown verified. The tests can actually fail.
• One live probe created zero junk data (both empty-title and empty-body posts were rejected 422).