refactor(argparser): decompose _process_auth into focused helpers

[atomadictech]

Summary

This is a targeted refactor of httpie/cli/argparser.py, specifically the _process_auth method which carries a developer TODO (# TODO: refactor & simplify this method.) and was identified as the module's highest-complexity hotspot.

Before / After

Metric	Before	After
_process_auth line count	74 lines	~20 lines
Max nesting depth (auth)	5 levels	2 levels
AuthCredentials construction duplicates	3	1 (_make_auth_credentials)
Nested closures	1 (check_options in _process_output_options)	0
Return type annotations	0	all methods

Changes

• _make_auth_credentials(key, value) — single DRY helper replaces three nearly-identical AuthCredentials(key=…, value=…, sep=…, orig=…) blocks
• _extract_url_credentials() — isolated: pulls user:pass from embedded URL
• _try_netrc_auth(plugin) — isolated: .netrc lookup path
• _build_plugin_auth(plugin) — isolated: credential parse/prompt/get_auth() call
• _process_auth() — now 20 lines, reads as a clear orchestration sequence
• _check_output_options(value, option) — extracted the nested check_options closure that lived inside _process_output_options
• Added -> None / -> argparse.Namespace / -> AuthCredentials annotations per the existing TODO at line 79

Verification

tests/test_auth.py          ✓
tests/test_auth_plugins.py  ✓
tests/test_cli.py           ✓
tests/test_downloads.py     ✓
tests/test_sessions.py      ✓
tests/test_offline.py       ✓
173 passed, 0 failed

No behavior changes — all public method signatures and the parse_args contract are identical.

---

Opened after running automated complexity analysis on the codebase with ASS-ADE. argparser.py scored highest on cyclomatic complexity (~104), nesting depth (9 levels), and mixed responsibilities.

[atomadictech]

CI Failures — Pre-existing Upstream Issues

I've investigated all failing checks. None are caused by this PR's changes. This PR only touches httpie/cli/argparser.py (auth processing decomposition) — no encoding, charset, or test infrastructure changes.

Failure breakdown

test_encoding.py — Big5 charset detection (all Python versions)

The two failing tests are:

• test_terminal_output_response_charset_detection[big5-...]
• test_terminal_output_request_charset_detection[big5-...]

These identical failures exist on upstream master as of the March 29 CI run (run 23703545489). The Big5 bytes are decoded as EUC-KR instead of Big5 — a charset detection regression unrelated to this PR.

Python 3.7 jobs (4-second failure)

Version '3.7' with architecture 'x64' was not found for Ubuntu 24.04.

Python 3.7 is no longer pre-installed on GitHub's ubuntu-latest (Ubuntu 24.04) runners. This is a CI workflow infrastructure issue that affects all PRs.

Verification

git diff upstream/master -- tests/test_encoding.py
# (empty — we did not touch test_encoding.py)

git diff upstream/master --stat
# httpie/cli/argparser.py | 182 ++++++++++++...
# REBUILD_REPORT.md, RECON_REPORT.md, docs/assade_analysis.md  (docs only)

This PR is clean. The upstream CI matrix needs:

1. Big5 charset detection fix (separate issue)
2. Python 3.7 runner removal or setup-python version pin

[atomadictech]

Update: Pushed a fix for the Big5 encoding test (commit 3a5f0ce).

Root cause: charset-normalizer 3.x returns johab (Korean) for the previous Big5 test string because the byte sequences \xa8\xf7\xad\xba are valid in both Big5 and Johab. The library scores Johab at 0.0 chaos (perfect) and Big5 at 0.1, so Big5 loses.

Fix: Updated CHARSET_TEXT_PAIRS Big5 entry to 臺灣正體中文，語言文字。 × 5. The full-width punctuation ，。 (U+FF0C, U+3002) encodes to byte patterns uniquely identifiable as Big5 — charset-normalizer 3.4.7 now returns big5 at 0.0 chaos for this content.

The Python 3.7 jobs will still fail (Python 3.7 is not available on Ubuntu 24.04 runners — upstream CI matrix needs updating).