[Feature]: Rich Result Cards with Metadata Badges

Parent PRD

#95

What to build

Replace the minimal search result display (icon + title + truncated description) with rich result cards that surface metadata at a glance.

Backend — SearchIndexItem:

• Add created_at: Optional[datetime] and updated_at: Optional[datetime] fields to the model.
• All managers implementing get_search_index_items() populate these from their source entities.
• Ensure extra_data consistently includes domain, status, owner across all searchable managers.

Frontend — New SearchResultCard component:

• Replaces the current <a> element in index-search.tsx.
• Renders: icon (existing logic), title (clickable link), truncated description.
• Inline badges row: type pill (e.g., "Data Product"), status pill (e.g., "Active" in green, "Draft" in gray), domain tag, top 2-3 tags as small pills.
• Certification badge slot (renders nothing until lifecycle work lands, graceful null handling).
• Responsive: badges wrap on narrow screens.

Frontend — Result count summary:

• Show a summary line at the top of results using facets from the API response: "3 Data Products, 5 Contracts, 12 Assets" as clickable chips that act as quick type filters.

Acceptance criteria

• SearchIndexItem has created_at and updated_at optional fields
• At least DataProductsManager, DataContractsManager, AssetsManager, DataDomainManager populate timestamps
• SearchResultCard component renders type pill, status pill, domain tag, and tags
• Missing metadata handled gracefully (no badge rendered if field is null/empty)
• Result count summary line shows counts by type from facets
• Count chips are clickable and apply type filter (updates URL params)
• Visual design consistent with existing Shadcn UI component style
• Component test for SearchResultCard (renders correctly with full and partial data)

Blocked by

• Blocked by #96 (needs SearchResult envelope with facets)

User stories addressed

• User story 7 (metadata badges on result cards)
• User story 8 (result count summary)

Start with the SearchIndexItem model and the get_search_index_items() implementations, then inspect index-search.tsx and the SearchResultCard entry point. Check #96 first because this work is blocked by the SearchResult envelope with facets. Done means timestamp and metadata fields are populated, cards and facet count chips handle missing data, and the component test covers full and partial data.