[robturner-kaluza]

Summary

• get_compatibility_level was deserializing the Schema Registry config response into a struct that only matched the JSON key "compatibilityLevel" (Confluent's global-config response shape).
• Confluent also returns "compatibility" (no "Level" suffix) for subjects with a subject-specific override set. Karapace always uses this shape.
• With no alias for "compatibility", serde would throw a deserialization error for those subjects, causing get_subject to fail entirely — meaning any subject with a non-default compatibility level couldn't be loaded. Only subjects inheriting the global BACKWARD default would display successfully, making it appear that all subjects were BACKWARD.

Fix

Added alias = "compatibility" alongside the existing alias = "compatibilityLevel" on the CompatibilityResponse struct so both response shapes are handled correctly.

Test plan

• Added two unit tests in backend/src/core/schema_registry/client.rs using httpmock:
  • test_get_subject_compatibility_level_field — covers {"compatibilityLevel": "..."} (Confluent global fallback, pre-existing behaviour)
  • test_get_subject_compatibility_field — covers {"compatibility": "..."} (Confluent subject-specific override / Karapace; this test would have failed before the fix)
• Manually verify a subject with an explicit non-default compatibility level (e.g. FORWARD) now displays correctly rather than failing to load