Fall back through toolkits for InChI conversion methods

[gaoflow]

Description

Molecule.to_inchi, Molecule.to_inchikey, and Molecule.from_inchi call ToolkitRegistry.call(...) without raise_exception_types=[], so they get the default behavior of re-raising the first toolkit's exception instead of continuing to the next registered toolkit. As a result the documented toolkit precedence/fallback never happens for InChI conversion: per #2172, OpenEye refuses InChI generation for molecules with more than 1024 atoms (which RDKit supports), but the registry propagates OpenEye's error rather than falling back to RDKit.

Fix

Pass raise_exception_types=[] at these three call sites, matching the convention already used throughout the rest of the Molecule API (e.g. assign_partial_charges, and as the test suite documents: "the Molecule API passes raise_exception_types=[] to ToolkitRegistry.call"). A higher-precedence toolkit that raises is now skipped in favor of the next one; if every registered toolkit fails, ToolkitRegistry.call still raises a single aggregate ValueError describing each failure.

Testing

Added TestToolkitRegistry::test_inchi_methods_fall_back_through_toolkits, which registers a stub wrapper whose InChI methods always raise ahead of RDKitToolkitWrapper and asserts that to_inchi, to_inchikey, and from_inchi skip the failing wrapper and succeed via RDKit. The test fails on main (the first toolkit's ValueError propagates) and passes with this change; it runs offline with only RDKit (no OpenEye needed). All existing InChI tests continue to pass.

Closes #2172.

---

Prepared with AI assistance under my direction; I reviewed and tested the change.

[j-wags]

Thanks @gaoflow - This looks promising. However because it is substantially AI generated, and because reviewing this PR will take about as much effort as making the changes myself, I'm just going to keep this at the same level of priority as the underlying issue. So I will review this when the underlying issue is actioned in our normal task planning.