feat(cli): generate a --no- negation for boolean inputs

[bdelanghe]

Closes #12.

(Placeholders below are written {field} rather than in angle brackets: the first revision of this description was created with angle brackets and they were silently stripped, leaving --no- and --limit (required). The code and commit message use the normal angle-bracket spelling.)

The problem

A z.boolean().default(true) had no way to be turned off from the CLI — only presence-is-true worked. Expressing "on by default, opt out on the command line" forced authors to declare a second override flag and compute the effective value by hand: two flags controlling one boolean dimension, purely to work around the missing negation.

What this does

parseArgs accepts --no-{field} for every boolean input:

input: z.object({ changedOnly: z.boolean().default(true) }),
// `check`                  →  changedOnly: true   (the default)
// `check --no-changedOnly` →  changedOnly: false

Every boolean gets one, not only the default(true) ones. Which spelling an author reaches for follows from the default, but a default is a value the verb may change — a conditionally-generated flag would vanish from every script using it the moment someone flipped one.

Two sets, deliberately not one

Per the design note on #12: the negation is the first derived CLI name — a valid flag that is deliberately not an input key. The single known set was load-bearing for two different questions, so it is split rather than widened in place:

set	answers	contents
known	"is this a declared input field?"	input keys — gates positional names, supplies negation targets
knownFlags	"is this an accepted flag name?"	known ∪ the negation names

So widening the CLI vocabulary cannot quietly make positionals: ["no-changedOnly"] legal. There is a test holding that line specifically.

Strict mapping is preserved

Three things halt rather than resolving to something surprising:

• --no-changedOnly=false — the negation is the value, so it accepts none.
• an input field that shadows a generated negation (a boolean loud beside a field literally named no-loud) — a spec error, checked up front like an undeclared positional, so it fails on every invocation rather than only the ones that pass the flag.
• a negation of anything not boolean or not declared (--no-slug, --no-bogus) — an unknown flag, as before.

A negation consumes no token, so myverb --no-loud alice still reads alice as a positional. Booleans stay scalar: --loud --no-loud is last-wins, the same rule every other scalar flag follows.

One adjacent fix, in the same renderer

toHelp now renders a boolean as --loud / --no-loud and prints each field's default. That surfaced an existing mislabel: z.toJSONSchema lists a defaulted field in required (the parsed output always carries it), so help marked --limit as (required) for a field that is precisely the omittable one. Beside a printed default it would have read as a flat contradiction — (required) (default: 20) — so a field with a default is no longer also marked required.

This is included rather than split out because it is one line in the function this PR already rewrites, and leaving it would mean shipping visibly self-contradicting help text.

Scope

Additive for existing specs — no currently-valid invocation changes meaning. Help text changes for defaulted and boolean fields. .release/cli-boolean-negation.md requests a minor bump.

Verification

Ran the repo's own CI command locally:

bun install --frozen-lockfile && bun run build && bun test && bunx jsr publish --dry-run --allow-slow-types

66 pass, 0 fail (17 new), build clean, JSR dry-run Success. All 9 checks are green on CI.

No [settings] or [org] toggles are required by this change.