Return the relevance score that search already computes

[a-optic]

The bug

search_memories computes a score for every row it returns — (embedding <=> %s::vector) as score for a semantic search, and a constant for the text and filter-only fallbacks — and its docstring says it returns "memory records with scores".

The field is never declared on MemoryResponse, so FastAPI's response_model filters it out before it reaches the caller.

Why it matters

POST /memories/search currently gives an ordering but no magnitude. A caller can rank results, but cannot tell a strong match from a weak one — and ranking alone cannot answer "is the best hit actually relevant?", which is the question that matters when the alternative is acting on an irrelevant memory. Today the only way to get the number is to bypass the API and query Postgres directly.

The change

One field, Optional[float] = None. GET /memories and GET /memories/{memory_id} share this model and produce no score, so their responses are unchanged.

Verification

Against a populated database — 53 embedded memories, snowflake-arctic-embed2 at 1024 dimensions:

POST /memories/search  "which books changed how I see the world"
  before:  score absent
  after:   score = 0.3666634909639195
           score = 0.38928308634373443

GET /memories   -> score: null   (unchanged, as intended)
GET /stats      -> 200           (unaffected)

The returned values match the cosine distance recomputed independently from the stored vectors to six decimal places, so the number reaching the client is the one pgvector computed.