refactor: unify model_type semantics by introducing sub_type field

This commit resolves the semantic confusion around the model_type field by
clearly distinguishing between:
- scanner_type: architecture-level (lora/checkpoint/embedding)
- sub_type: business-level subtype (lora/locon/dora/checkpoint/diffusion_model/embedding)

Backend Changes:
- Rename model_type to sub_type in CheckpointMetadata and EmbeddingMetadata
- Add resolve_sub_type() and normalize_sub_type() in model_query.py
- Update checkpoint_scanner to use _resolve_sub_type()
- Update service format_response to include both sub_type and model_type
- Add VALID_*_SUB_TYPES constants with backward compatible aliases

Frontend Changes:
- Add MODEL_SUBTYPE_DISPLAY_NAMES constants
- Keep MODEL_TYPE_DISPLAY_NAMES as backward compatible alias

Testing:
- Add 43 new tests covering sub_type resolution and API response

Documentation:
- Add refactoring todo document to docs/technical/

BREAKING CHANGE: None - full backward compatibility maintained

py/services/lora_service.py

@@ -23,6 +23,9 @@ class LoraService(BaseModelService):
 
     async def format_response(self, lora_data: Dict) -> Dict:
         """Format LoRA data for API response"""
+        # Get sub_type from cache entry (new field) or fallback to model_type (old field)
+        sub_type = lora_data.get("sub_type") or lora_data.get("model_type", "lora")
+        
         return {
             "model_name": lora_data["model_name"],
             "file_name": lora_data["file_name"],
@@ -43,6 +46,8 @@ class LoraService(BaseModelService):
             "notes": lora_data.get("notes", ""),
             "favorite": lora_data.get("favorite", False),
             "update_available": bool(lora_data.get("update_available", False)),
+            "sub_type": sub_type,  # New canonical field
+            "model_type": sub_type,  # Backward compatibility
             "civitai": self.filter_civitai_data(
                 lora_data.get("civitai", {}), minimal=True
             ),