feat(metadata_expert): add/update/delete open metadata type definitions

[dwolfson]

Summary

Adds the five open-metadata type-definition calls that the refreshed Egeria-api-metadata-expert.http documents and MetadataExpert lacked (the audit's metadata-expert section: 5 missing -> 0, 27 OK, 0 mismatched):

• add_enum_def / add_type_def (entity, relationship or classification) / update_type_def (a patch carrying only what changes) / delete_type_def / delete_enum_def.
• New request models OpenMetadataEnumDef, OpenMetadataTypeDef, OpenMetadataTypeDefPatch declare only the documented fields and use extra='allow'. These mirror deep Egeria beans (relationship ends, enum elements, updateToVersion, typeDefStatus, ...); modelling every field by hand risked silently dropping some under PyegeriaModel's default extra='ignore' (the ISSUE-62 gotcha). A test pins that undeclared fields survive.
• The two deletes pass typeDefName / enumDefName as query parameters with no body, as the .http shows.

Live verification (2026-10-05, dev quickstart platform)

call	result
add_enum_def	works; returns the new GUID as a plain string
add_type_def	works; returns the new GUID; read-back shows the type with its enum-typed attribute intact
delete_type_def	works
update_type_def	rejected by the server, not by pyegeria: OMRS-REPOSITORY-400-069 ... mandatory field updatedBy set to null. Egeria's getTypeDefPatch converter is never given the calling user (checked on origin/main, 2026-10-01), and the patch bean has no field a client could use. Logged as ISSUE-124; docstring warns.
delete_enum_def	500 OMRS-CONTENT-MANAGER-500-001 unknown TypeDef for an enum get_attribute_types still lists, even after the only type using it was deleted. Logged as ISSUE-125; docstring warns.

Re-tested on the rebuilt platform (2026-10-05, image built 14:19Z from Egeria main 449ad06894, egeria-main restarted 14:39Z): both failures reproduce identically (update_type_def with the same updatedBy error on a fresh throwaway type; delete_enum_def with the same unknown TypeDef error, and the enum also survived the restart). So neither is a stale-build artefact, and Egeria's source at that commit still has both causes (the patch converter never sets updatedBy; the GUID map is written in only one place).

The calls match the documented API; the two failures are Egeria server bugs and are logged rather than worked around. A stray throwaway enum, PyegeriaTmpCuisineType, is left on the shared dev platform (unused; a retry after the platform's next restart is worthwhile).

Test plan

• Rebased onto current main (it conflicted with feat(product-manager): subscription types and ODCS/ODPS documents, with Dr.Egeria commands #427/fix(omvs): CollectionManager subclasses run the base constructor; delete cascade reaches the server (ISSUE-126, ISSUE-127) #429 in models.py and models/__init__.py; both sides kept); full micro-suite passes
• 9 micro-tests: URL, verb, body, query params, returned GUID, undeclared fields kept, bad bodies rejected before any request
• scripts/omvs_audit.py --service metadata-expert: 0 missing, 0 mismatched; the existing endpoint-contract test still passes
• Live add / read-back / delete-type against a real server (table above)
• Both server failures re-confirmed on the rebuilt platform
• Live update_type_def and delete_enum_def success: blocked by the two server bugs (ISSUE-124, ISSUE-125)

🤖 Generated with Claude Code