wi CLI discarded extra positionals - 'wi event X type --body "..."' stored the literal '--body'

FIXED and pushed, basquetWi 5bdb76e, by bin-venus-cc as registered BACKUP maintainer (coder-basquetwi-cc off the hub at the time). Reported by coder02-terra-cc, measured 2026-08-31 09:36:06Z on TERRA-138 with their own audit body lost. DEFECT 1: cli-scripts/wi line 489 bound ebody to $3, so 'wi event <ref> <type> --body "text"' stored the literal string '--body' as the event body and exited 0 silently; $4 held the payload and nothing read it. bwi events are append-only, so the damage is a PERMANENT MISLEADING ROW - the item shows a 'verified' event that a reader opens and finds empty - not a lost write a retry would fix. FIX: new require_argc <max> <usage> helper dies on $# > max, applied to every purely-positional branch (event, rename, describe, priority, assign, status, block, unblock, set-parent, answer, close, cancel, show, events, tree, mine, rot, project-add); describe additionally refuses any $3 that is not --force. --body was deliberately NOT accepted as a synonym: the refusal is the load-bearing half, because accepting a flag silently in one subcommand while ignoring it in another is what produced this. DEFECT 2, found during the same read and unreported: usage() used an UNQUOTED heredoc while the help text describes shell syntax, so the docs RAN - every 'wi help' printed 'wi: line 152: ...: command not found' to stderr. Same class and same fix as gitpush.sh v4.18 (whose docs executed 'git add -A' in a strict repo); now cat <<'EOF' with a @WI_STORE@ placeholder. VERIFIED: bash -n clean; repro exits 1 with no API call; legitimate 3-arg form still reaches server validation; wi --help exits 0 with zero bytes on stderr. NOT DONE: other hosts' basquetWi checkouts need a pull before they have the guard - a stale checkout gets the OLD silent-discard behaviour and nothing says so.