[Aschenbath]

transform_error could only pass a target type to format_exception for failures inside classes and iterables, where the generated hooks attach notes carrying the type. A failure at the top level — most commonly structuring a bare primitive — reached the formatter with no type:

>>> transform_error(raised_by(lambda: Converter().structure("x", int)))
['invalid value @ $']  # now: ['invalid value for type, expected int @ $']

Changes:

• cattrs.errors gains a TypeValidationNote (exported from cattrs like the other notes): a note carrying the target type, modeled on AttributeValidationNote/IterableValidationNote.
• BaseConverter.structure() attaches such a note when the dispatched hook raises, detailed_validation is on, and the exception carries no notes yet — so the note records the innermost failing target (the method is also called recursively, e.g. by union disambiguation, and only the first, noteless failure point attaches one). With detailed_validation=False nothing is attached.
• transform_error consults the new note wherever it previously passed None to format_exception (the bare-exception branch and the note-less members of class/iterable groups), so custom format_exception implementations also receive the type.

Tests: new cases in tests/test_v.py cover top-level int/float failures, a custom format_exception receiving the type, and the detailed_validation=False behavior. test_v.py + test_errors.py: 33 passed. Full test suite: 1087 passed, 15 xfailed, 20 skipped; the only 2 failures are test_preconf.py tomllib tests, which fail identically on unmodified upstream main in this environment (an AttributeError from the installed toml library, unrelated to this change). A changelog entry is added under NEXT in HISTORY.md.

Fixes #401

[Aschenbath]

Closing this one myself: I opened too many PRs here in a short time, which isn't fair to your review queue — sorry about that. I'm leaving #827 and #822 open. If this fix is something you'd want, I'm happy to reopen or rebase it later.