fix(importers): rank pre-filter candidates by relevance before the caps

[jramos]

The defect

RelevanceFilter.filter_and_score qualified candidates with a boolean predicate, then truncated:

candidates = [m for m in messages if _is_relevant_to_skill(...)]   # boolean, no strength
candidates = candidates[:max_examples * 3]                         # source-then-import order

No ranking signal existed anywhere before the cap, so on any skill where heuristic matches overflow it, the strongest matches were discarded before the LLM scorer ever saw them. build_dataset_from_external concatenates per importer, so an overflowing source could crowd out a later one entirely.

Confirming the defect surfaced a second, wider path to the same loss: the scoring loop breaks at len(examples) >= max_examples, so candidate order decides the output set on every run — not only when the cap engages.

The existing cap test asserted the resulting count and never which candidates survived, which is why the suite couldn't see this.

The fix

_relevance_score returns a tiered tuple (name_match, name_words, keyword_overlap), and _is_relevant_to_skill becomes any() over it. Candidates sort strongest-first ahead of both caps.

A tuple rather than weighted integers, deliberately: skill_name is caller-supplied and unbounded in length (traced to a free-form --skill CLI option with no length validation), so no fixed set of weights can stop a long name's word count from outranking a full-name match. A tuple key cannot be violated by input.

The keyword tier contributes 0 below two overlaps. That is the one way this change could have silently widened the qualifying set instead of reordering it, so it has its own test.

sorted() is stable, so equally-scored messages keep import order and the seeded backfill is untouched — no new nondeterminism.

Verification

10 tests. Three are genuine behavioral reds that fail against the base commit with real assertion failures — one per cap, plus one pinning the scorer's call order. Two more fail pre-change only because the new function doesn't exist yet, which is an artifact of testing a new symbol and is not evidence the old code behaved differently; the rest are invariant and characterization tests, labeled as such.

• Set preservation is proven by a 2000-case fuzz plus 7 hand-picked edges (empty skill name, whitespace name, empty text, overlap of exactly 1, case mismatch, short name words, empty skill text) against a verbatim copy of the previous predicate as an oracle.
• Tier separation is mutation-verified. Review caught that every ordering test used a single-word skill name, making the middle tier indistinguishable from the top — a weighted sum would have passed all of them. A multi-word case was added where the tiers disagree, and mutating the implementation into name_match * 100 + name_words * 10 + keyword_overlap fails exactly the two new tier tests and no others.
• Tie ordering is pinned, not merely compared run-to-run; ties exceeding the cap and the backfill-only path are both covered.
• The pre-existing relevance tests are deliberately unmodified — they are the equivalence proof.
• Full non-slow suite: 1773 passed (1763 baseline + 10), ruff clean.

Known non-goal

The duplicated mock_dspy fixture is left alone. Hoisting it would touch three test classes and weaken the "no existing test line altered" property that makes the pre-existing tests a clean equivalence proof; it belongs in its own cleanup.

Note for future runs

Eval sets drawn after this change differ from earlier ones in both composition and train/val/holdout assignment, so they should not be compared naively across this boundary. Recorded in the triage doc.

Stacking

Based on the triage-doc branch so the action-item row it flips exists in the same diff. GitHub will retarget this to main when that PR merges.

Addresses the relevance-ranking item raised upstream as NousResearch/hermes-agent-self-evolution#149, and closes the recall follow-up deferred from NousResearch/hermes-agent-self-evolution#26. Implemented natively; no upstream diff applied.