Normalize model type / architecture field semantics and align UI, registry, and CycloneDX mapping

[e2hln]

The current AIBOM output and UI expose multiple “type” and “architecture” concepts that overlap semantically but originate from different layers:

• CycloneDX components[].type → shown in UI as Type
• HF config.json:model_type → mapped to modelCard.modelParameters.modelArchitecture → shown in UI as Architecture
• HF config.json:architectures[] → stored as component property

This results in:

• Ambiguity between component type (CycloneDX) and model architecture
• Confusion between HF model_type and architectures[]

For example (Nanbeige/Nanbeige4.1-3B case)

• UI “Type” = machine-learning-model (CycloneDX component type)
• UI “Architecture” = llama (derived from HF model_type)
• HF architectures = ["LlamaForCausalLM"] (not surfaced clearly in UI)

This makes provenance unclear or confusing.

Goals

1. Normalize terminology in the UI to clearly distinguish:

• CycloneDX component classification
• Model family (HF model_type)
• Concrete implementation class (HF architectures[])

2. Optionally expose field provenance (source file + extraction method) in the Human-Friendly View.

Proposed Changes
A. UI Terminology Normalization
Rename in Human-Friendly View:

• Type → Component type (CycloneDX)
• Architecture → Model family (HF model_type)
• Add (if present): Model implementation (HF architectures)

B. Provenance (optional but recommended)
Expose, per field:

• AIBOM JSONPath
• Source file (config.json / README / API / inference)
• Extraction method
• Confidence (if available)

Acceptance Criteria

• UI clearly differentiates:
  --- CycloneDX component type
  --- Model family
  --- Implementation class
• Registry JSONPath matches emitted AIBOM JSON.
• Field Checklist location matches registry JSONPath.
• No duplicate or overloaded “type/architecture” semantics remain.