fix: never resolve derived characteristic types by uuid

[bobby-smedley]

🎯 What does this PR do?

The skip guard in both assignment parsers matched only DerivedRelationType. DerivedAttributeType passed it, and then got classified as a normal attribute because the attribute check is a HasSuffix("AttributeType") match (it covers StringAttributeType, DateAttributeType, and so on). So a derived attribute became a writable slot in prepare_create_asset and got resolved via /rest/2.0/attributeTypes/{id} — a lookup the platform stops answering for derived types in 2026.10.

Derived relation types were already excluded as non-creatable in #104 (04fb4e1); this applies the same rule to derived attribute types, which that PR missed because DATs don't appear in any payload yet.

• Both parsers now share isDerivedDiscriminator().
• New test drives the tool against a mock DGC behaving like a post-change instance: it serves an assignment carrying a derived relation type and a derived attribute type, 404s derived ids, and fails if chip looks either up. Red before the fix, green after.

Relation types were already safe. Derived attribute types aren't released yet, so no live impact today.

✅ Checklist

• My code follows the style guidelines of this project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation (if needed).
• My commit messages follow the Conventional Commits standard.