Coverage eval reports 100% even when retrieval isn't meaningfully working

[camunity]

Description

evaluate_rag_coverage() only checks whether a requirement retrieved any chunk, not
whether the chunk is actually a good semantic match. If chunking degrades (see #1), every
requirement "matches" the one giant chunk, producing a misleadingly perfect coverage score.

Suggested approach

Add a similarity-score threshold to retrieve_relevant_experience() and have the eval report
count a requirement as "covered" only if its best match is above that threshold, not just
present.

[Divergent-Code]

PR #6 implements exactly this. It adds a cosine-distance threshold (RELEVANCE_MAX_DISTANCE) inside retrieve_relevant_experience() and drops any match beyond it, so a requirement with no good semantic match now surfaces as an empty evidence list instead of the nearest-but-irrelevant chunk. evaluate_rag_coverage() counts a requirement as covered only when its evidence list is non-empty, so the score reflects real matches rather than mere presence. The Chroma collection is also created with cosine space (metadata={"hnsw:space": "cosine"}) so the distance threshold is meaningful.

Note this mitigates but doesn't fully resolve the root cause in #1 (a single giant chunk can still match many requirements loosely) — the threshold and the chunking fix are complementary.