fix: don't crash startup on unknown litellm exceptions unless strict

[kingmakeruix]

What: honor the strict flag in LiteLLMExceptions._load ÔÇö unknown litellm exceptions are caught with generic info by default, still raise with strict=True.

Why: any new exception type added by litellm crashed aider at startup with ValueError: ... is in litellm but not in aider's exceptions list (see #5714). Runtime code and tests already distinguish the two modes ÔÇö __init__ uses the default, test_litellm_exceptions passes strict=True ÔÇö but the flag was ignored.

How: non-strict registers unknown exceptions with ExInfo(None, None, None), matching the existing get_ex_info fallback (reported cleanly, no retry loop). Added 2 tests: lenient-by-default and strict-raises.

Checklist:

• Follows CONTRIBUTING.md (pytest, no type hints, <=100 cols)
• Tests pass: tests/basic/test_exceptions.py 9/9
• Existing strict fail-fast test unaffected

[CLAassistant]

All committers have signed the CLA.

[kingmakeruix]

Thanks — following up on this one, since it has been open a while.

All four CI workflows on this PR are sitting in action_required and have never executed:

• Ubuntu Python Tests
• Windows Python Tests
• Docker Build Test
• pre-commit

Only license/cla has actually run, and it passes. So the "tests pass" claim in the description is currently backed by local runs only (tests/basic/test_exceptions.py, 9/9) and has never been confirmed by CI on this branch.

I am not sure what the trigger is — it looks like the fork-PR gate rather than anything specific to this change, since other external PRs on main appear to be in the same state. If someone could approve the workflow runs, or tell me the expected path for a contributor in this situation, I would appreciate it. Happy to rebase, re-split, or adjust anything if that is what is needed to get it reviewed.