fix(cli): restore Click and Windows locale compatibility

[tianmind-studio]

Summary

• cap Typer below 0.26 while omi-cli subclasses the external click.ClickException API
• run the two structured-exception unit tests in non-standalone mode so they continue to inspect the original CliError payload
• read the public OpenAPI contract explicitly as UTF-8 on locale-encoded Windows hosts

Why

Typer 0.26 introduced a breaking boundary by vendoring Click and no longer supporting direct external Click integration: https://typer.tiangolo.com/tutorial/click/. The current typer>=0.12,<1.0 range therefore resolves to a version whose exception base is different from omi-cli's CliError base. Six stable exit-code/error-rendering tests fail under Typer 0.26.8.

Separately, Path.read_text() inherits the Windows system code page. On a GBK host, all four CLI/OpenAPI contract tests fail while decoding the repository's UTF-8 JSON.

This keeps the last compatible Typer series available (0.25.x) rather than pinning one patch release, and makes the contract reader independent of host locale.

Testing

• fresh dependency resolution: Typer 0.25.1 + Click 8.4.2
• targeted error and OpenAPI tests under PYTHONUTF8=0: 12 passed
• Windows CLI suite excluding the two owner-only ACL tests addressed by fix(cli): enforce owner-only config ACLs on Windows #9764: 123 passed, 2 deselected
• Black and isort: passed
• git diff --check: passed

Before the fix, the six external-Click error paths failed under Typer 0.26.8 and the four OpenAPI cases failed with UnicodeDecodeError under the Windows locale.

[Git-on-my-level]

Thanks for the focused CLI compatibility fix. I verified the Python CLI suite behavior locally in a clean venv with secrets stripped:

• with typer==0.26.0, the suite reproduces the six Click/Typer exception-boundary regressions described in the PR
• after reinstalling the proposed typer>=0.12,<0.26 cap, the Python CLI suite passes (125 passed)
• the targeted OpenAPI contract tests also pass once the sparse checkout includes docs/api-reference/openapi.json, and the explicit UTF-8 read is the right Windows-locale fix

I’m leaving this as a positive signal rather than a formal approval because this changes dependency bounds and the current automation policy requires maintainer review for dependency-sensitive changes. Maintainer check should mainly confirm that holding Typer below 0.26 is the desired short-term compatibility strategy versus refactoring the CLI exception handling for the newer Typer boundary.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.