Characterize converter catalog, selection, orchestration, and concurrency

[DenWin]

Parent testing program: #16. Blocked by #17.

Evidence

src/converters/main.ts hard-wires all converter adapters, precomputes capability maps, selects converters, builds output names, chunks concurrent work using MAX_CONVERT_PROCESS, executes conversions, catches failures, and writes database status records.

This important orchestration module is absent from the current coverage report.

Required characterization tests

Catalog and capability behavior

• All declared source/target pairs are discoverable.
• Input/output normalization aliases and case handling.
• Preferred converter ordering where multiple adapters support a pair.
• Explicit converter selection.
• Implicit/default selection.
• Unsupported source-target and unknown converter behavior.
• Duplicate capability entries and returned-object mutation behavior.
• getAllTargets/getAllInputs consistency with adapter declarations.

Orchestration

• Input and output paths for files with no extension, multiple dots, regex-significant characters, Unicode, and normalized extensions.
• Correct output database record for success, unsupported conversion, and converter failure.
• Converter options propagation.
• MAX_CONVERT_PROCESS zero/default, one, exact chunk, and remainder behavior.
• Concurrency never exceeds the configured limit.
• Define whether one failure stops later chunks and how already-started files are recorded.
• Job completion reflects individual output outcomes.

Safe refactoring path

1. Add characterization tests through handleConvert and exported catalog functions.
2. Demonstrate sensitivity with controlled fake converters and a temporary database.
3. Extract a deep conversion-catalog module and conversion-orchestrator module only while green.
4. Keep process execution in converter adapters; do not create pass-through wrappers.

Acceptance criteria

• Catalog invariants and every selection branch are covered.
• Concurrency and partial failure are deterministic under a controlled scheduler/fake adapter.
• Output naming and persistence are tested as observable behavior.
• Capability results cannot be accidentally mutated across requests.
• Tests survive replacing registry implementation details.