Restore Python's builtin Exception shadowed by AlgorithmImports star imports

[jhonabreul]

Description

AlgorithmImports.py does from System import *, which shadows Python's builtin Exception with System.Exception. Pure-Python exceptions (TypeError, KeyError, ...) do not derive from it, so except Exception: silently fails to catch them:

try:
    self.history(...)  # raises TypeError
except Exception as e:  # actually System.Exception -> does NOT catch
    self.log(f"handled: {e}")

The fix restores the builtin after the star imports:

• Exception = builtins.Exception at the end of AlgorithmImports.py. The builtin also catches CLR exceptions raised into Python, so it is strictly broader than the previous binding.
• import System alongside the star import, so the CLR type stays reachable as System.Exception.

Behavior changes: raise Exception("msg") now creates a Python Exception instead of a System.Exception (both propagate and log fine), and isinstance(x, Exception) is broader.

Related Issue

N/A

Motivation and Context

Python algorithms commonly wrap calls in try/except Exception and still crash with "unhandled" TypeError/KeyError. The code is idiomatic Python and correct anywhere except inside Lean.

Requires Documentation Change

No.

How Has This Been Tested?

New Tests/Python/AlgorithmImportsTests fixture, written red-first against master:

• ExceptionIsThePythonBuiltinException — Exception is builtins.Exception after from AlgorithmImports import *.
• ExceptClauseCatchesPythonExceptions — except Exception: catches a raised TypeError.
• ExceptClauseCatchesClrExceptions — except Exception: still catches a CLR exception thrown from C# (no regression).
• StarImportsDoNotShadowPythonBuiltins — audits every exported name against builtins; before the fix it reported exactly Exception, now empty. Guards against future shadowing.

Full QuantConnect.Tests.Python and QuantConnect.Tests.Common.Exceptions fixtures (1458 tests): all green.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>