Allow replacing unused auto-created converters

[mdepinet]

Summary

When get_converter() auto-creates a converter for a type pair, it now uses _AutoConverter (an internal subclass) that tracks whether convert() has been called. A ProtoConverter subclass registered later can replace an unused _AutoConverter, eliminating class-definition ordering constraints in most cases.

This was the main friction point during the Fixie migration — parent converters had to be defined after all their leaf converters so that auto-resolution would find the registered subclasses. With this change, definition order is irrelevant for auto-convertible subtypes as long as all subclasses are defined before the first convert() call. Subtypes that cannot be auto-converted (e.g. field names differ between source and destination) still need their custom converter defined before the parent.

Invariant preserved: once a converter has been used (convert() called), it's locked in and replacement raises RuntimeError. This ensures convert() behavior doesn't change after first use.

Unhandled field errors are still caught at construction time. If a nested type genuinely can't be auto-converted, auto-creation fails with NotImplementedError when the parent registers — exactly as before. The only thing that changes is: if auto-creation succeeds, the result can be replaced by a subclass later.

Test plan

• just — 41 passed, pyright/ruff/deptry clean
• New test: test_replace_unused_auto_converter — verifies replacement succeeds
• New test: test_replace_used_auto_converter_fails — verifies used converters are locked

🤖 Generated with Claude Code

[mdepinet]

Closing per review feedback — the strict ordering rule is simpler, more predictable under schema evolution, and already necessary for non-auto-convertible subtypes. The partial relaxation adds complexity without meaningful benefit since real codebases adopt leaf-first ordering anyway.