Publish typed algorithm result kinds in the API once the UI generates its types from it

[mihow]

Summary

The occurrence history endpoint (#1461) publishes each algorithm result's data as plain JSON in the OpenAPI schema. The server validates data against a pydantic model per result kind (ami/ml/results/schemas.py), and the UI types it by kind by hand (ui/src/data-services/models/occurrence-history.ts). An earlier revision of #1461 also published one typed OpenAPI component per kind. It was removed before merge because nothing consumed it yet, and because naming its enums made config/settings/base.py import application code.

This ticket is the reminder to bring typed result kinds back to the schema once the UI generates its TypeScript types from the OpenAPI schema, so the hand-written types and the server models cannot drift.

What to do then

1. Publish one component per kind, built from the registry (ALGORITHM_RESULT_DATA_MODELS): kind as a literal and data as the kind's JSON schema, inside the history's oneOf. The removed implementation is in the history of Record any algorithm's results on occurrences in a standard way, and show them in each occurrence's history #1461 (_result_entry_component in ami/main/api/serializers.py).
2. Name the single-value enums without importing app code into settings, for example with a drf-spectacular postprocessing hook, or by building ENUM_NAME_OVERRIDES lazily.
3. Keep data models flat: nested models and Enum fields emit #/definitions/... references that do not resolve inside OpenAPI. Restore the test that checks each kind's schema is closed and flat.
4. Replace the hand-written per-kind interfaces in the UI with the generated ones.

Depends on: OpenAPI-to-TypeScript generation in the UI (not started).