bug: make pre-parse JSON detection follow Click option grammar

[codeforester]

Goal

Make the raw-argv decision for pre-parse error rendering follow the same option grammar Click applies to the actual invocation.

Background

_json_requested() scans for exact declarations anywhere in args. It does not recognize a JSON short option inside a valid short-option cluster, and it continues scanning after --. Successful parsing can still activate JSON through Click, so the mismatch is exposed specifically when another token causes an early parse error.

This is a distinct follow-up to #212, which fixed combined positive/negative declarations and default precedence.

Reproduction and evidence

Framework reference: 263d893 on main.

For a JSON lifecycle option declared as --json, -j and a separate -x flag:

invoke(app, ["-xj", "--unknown"])
exit=2
stdout=''
stderr="Usage: ... Error: No such option '--unknown'."

The user explicitly selected JSON through Click's supported -xj cluster, but the one-envelope contract is lost.

Conversely:

invoke(app, ["--", "--json"])
exit=2
stdout='{"schema":"base-cli.error", ...}'
stderr=''

Here --json is positional data after the option terminator, yet the pre-parser incorrectly activates JSON.

Scope

• Recognize supported short-option clusters, including positive and negative JSON aliases where applicable.
• Stop option interpretation at Click's -- boundary.
• Preserve last-explicit-declaration, environment, default-map, and option-default semantics.
• Add error-path tests; the existing combined-short success test is insufficient.

Acceptance criteria

• An early parse error after -xj emits exactly one JSON error envelope.
• A --json token after -- does not select JSON mode.
• Explicit negative declarations override positive/default values consistently.
• Human and machine output remain separated for all tested parse failures.

Project fields

• Status: Backlog
• Priority: P1
• Area: CLI
• Initiative: v1.0 Readiness
• Size: M

Ownership

• Assignee: @codeforester