Resolve isomer engine names through the shared registry (item 5, step 3)

[isayev]

Breaking, in one narrow way: an unknown isomer engine name raises
ConfigurationError rather than ValueError, so the CLI reports exit 2 with a
hint instead of exit 1 as an unexpected error.

The registry added in #162 now has a caller — main is no longer carrying an
unused module.

Three statements of one fact become one

_ENGINE_TYPES was a tuple. The "unknown engine" error hand-wrote its own list
of alternatives. available_engines() restated the tuple. Nothing connected
them.

Construction deliberately stays put

The if/elif ladder in create is untouched, and that is the design working
rather than the job being half-done. Its own comment records why it exists: each
branch names exactly the arguments its engine takes, so an argument no engine
reads cannot survive there unnoticed.

A registry that also built the engine would need one signature covering all
three backends — the keyword bag that property exists to prevent, and the same
defect the plan records for threshold meaning three different quantities. #162
was designed not to own construction for exactly this reason; this is the first
place it pays off.

On the exception change

It is in the CHANGELOG rather than absorbed as an implementation detail: a
caller catching ValueError around IsomerEngineFactory.create stops catching
it. ConfigurationError is the right type — a bad engine name is a
configuration problem, and it is already what every other bad backend name in
the package raises. The message now also enumerates the alternatives, which the
old one did inconsistently.

Suite: 1756 passed, 1 skipped, 70 deselected.

Still to come

Step 2 — moving ModelFactory on — is the larger half, because of the
three-parallel-lists finding recorded in #162: _adapters (2 entries),
available_models() (a hand-written literal with 6), and ENGINE_INFO (6),
holding different sets and connected by nothing.