fix: release Micro-Manager devices on interpreter exit

[hinderling]

Summary

• Register an atexit hook in PyMMCoreMicroscope.__init__ that cancels any running MDA and calls mmc.unloadAllDevices() when the Python interpreter shuts down. Hook is keyed on a weakref so it doesn't pin the microscope instance.
• Introduce an overridable _teardown_hardware() method on the base class. Subclasses with extra cleanup (background threads, serial ports, etc.) override it and chain to super()._teardown_hardware() last.
• Moench.shutdown() now delegates to _teardown_hardware() so the explicit API and the atexit path run the same code. Moench._teardown_hardware() stops the wakeup_dmd thread before the base unload, to avoid racing the thread's next displaySLMImage call.

Why

Without explicit unload, device adapters stay bound to the dying Python process and the next process trying to load the same Micro-Manager configuration fails to acquire them. On the Moench rig this manifests as the Andor Mosaic 3 DMD refusing to load after any kernel restart that didn't go through mic.shutdown() (a script crash, a force-killed Jupyter kernel, etc.).

pymmcore-plus historically did this in atexit itself but removed it in pymmcore-plus#572, so cleanup is now the caller's responsibility. PyMMCoreMicroscope is the right layer for FARO — every subclass (Moench, Jungfrau, Niesen) gets the protection in one place.

Verification

Tested end-to-end on the Moench rig:

• Phase A: fresh python.exe loads TiMoench.cfg, registers the hook, exits naturally. Atexit confirmed firing via the call chain visible in the exit-time logging trace (_atexit_teardown → _teardown_hardware → unloadAllDevices).
• Phase B: separate brand-new process spawned after Phase A had fully exited. Loaded the same config back-to-back; Mosaic 3 acquired cleanly with mosaic3_loaded=True, no device in use error.

Without this fix, Phase B would hang or raise on Mosaic 3 acquisition.