🔴 [ARCH] SearchMatch.similarity is a Frankenstein - needs separated scores #10

Problem

SearchMatch.similarity currently represents THREE different things:

• text search: ts_rank (PostgreSQL relevance)
• semantic search: cosine similarity

This is a contract lie that breaks:

• Debugging (why did a chunk win?)
• Threshold tuning (can't set per-channel thresholds)
• Reranking pipelines
• Evaluation metrics

Current Anti-Pattern

# In RRF - MUTATING the original object
match.similarity = scores[cid]  # Overwrites original score!

Solution: Separated Scores Model

Create a new SearchHit model with explicit scores:

class SearchHit(BaseModel):
    chunk: Chunk
    document_title: str
    document_source: str
    
    # Explicit scores - None if not computed
    semantic_score: float | None = None
    text_score: float | None = None
    fusion_score: float | None = None
    
    @property
    def best_score(self) -> float:
        return self.fusion_score or self.semantic_score or self.text_score or 0.0

Files to Change

• src/core/schemas/search.py - New SearchHit model
• src/infrastructure/database/supabase_repository.py - Return proper scores
• src/services/rag_service.py - Don't mutate, create new objects

Acceptance Criteria

• SearchMatch replaced with SearchHit
• RRF creates new objects instead of mutating
• Each score type is traceable