Report invalid --format-options as a CLI error, not a traceback

[VXNCXNX]

An invalid --format-options value exits with an unhandled argparse.ArgumentTypeError traceback instead of the normal HTTPie error:

$ http --offline --format-options=json.indent:x pie.dev/get
  File "httpie/cli/argtypes.py", line 244, in parse_format_options
argparse.ArgumentTypeError: invalid value 'x' in 'json.indent:x' (expected int got str)

Same for an unknown section (--format-options=json) or key (--format-options=json.nope:1). _process_format_options calls parse_format_options outside argparse's own type machinery, so the error escapes to the top level. It is now caught and routed through self.error, which is what _guess_method and _parse_items already do a few lines above; --traceback still re-raises, matching those two.

After the fix the same command prints error: --format-options: invalid value 'x' ... and exits 1. Three parametrized cases added in tests/test_output.py. Suite is green apart from two pre-existing big5 charset failures in test_encoding.py, identical on an unmodified checkout: 1020 passed, 2 failed.

AI disclosure: written with Claude Code. I ran the CLI before and after and checked the mutation myself.

[VXNCXNX]

The red CI here is master, not this PR.

Tests and Coverage fail on exactly two cases, test_terminal_output_response_charset_detection[big5-...] and its request twin. Both fail identically on pristine master, which I checked out clean and ran rather than inferring:

$ git checkout origin/master && pytest tests/test_encoding.py -k 'charset_detection and big5'
2 failed, 51 deselected

httpie's own master CI run on 29 Aug fails the same two, so this is not something the PR branch introduced. This PR touches httpie/cli/argparser.py and tests/test_output.py only, and the rest of the suite is green: 175 passed, 2 failed locally, the 2 being those.

Root cause, since it is two lines to reproduce:

>>> import charset_normalizer as cn          # 3.5.1
>>> cn.from_bytes(('卷首'*9)[:17].encode('big5')).best().encoding
'johab'

The detector settles on johab, a Korean encoding, so the payload comes back as 뻥솤뻥솤... instead of 卷首卷首.... The test asserts the round trip. charset-normalizer is not pinned in setup.py, so this started failing when a new version shipped rather than from any change here.

To be fair to the library, the fixture is a short, highly repetitive payload, which is close to the worst case for statistical charset detection, and big5 and johab overlap in that byte range. So this reads more like an over-specified test than a regression in the dependency.

Happy to send a separate PR for it if that would help, either pinning the dependency or making the fixture less ambiguous. I have left it out of this one since it is unrelated to the --format-options change.