neighbors CALLS: tighten Decision 20 OTHER-fallback hint signal

[HumanBean17]

Context

Follow-up from PR #182 review (#182 (comment)), item 4.

PR-2 ships TPL_NEIGHBORS_CALLS_ROLE_FILTER_OTHER_FALLBACK per Decision 20 / HV30 awkward case in propose/CALLS-NOISE-AND-RESOLUTION-PROPOSE.md: when edge_filter.callee_declaring_role is SERVICE or REPOSITORY, filtered results are empty, and count_calls_for_symbol (unfiltered total) is ≥ 5, suggest exclude_callee_declaring_roles instead of exact role match.

Problem

Methods with many outbound CALLS but zero legitimate SERVICE/REPOSITORY callees (e.g. mostly OTHER / JDK / accessors) can still trigger the hint — noisy or misleading guidance.

Proposed direction

• Tighten the signal, e.g. require at least one non-OTHER callee_declaring_role among unfiltered CALLS before suggesting the OTHER-fallback path, or compare filtered-empty vs a role-distribution threshold.
• Document any semantic change vs Decision 20 in propose (short amendment) if the locked threshold changes.
• Add/adjust test_neighbors_calls_other_fallback_hint so it asserts the tighter predicate and does not over-fire on legitimately zero-SERVICE methods.

Scope

• mcp_hints.py (neighbors_calls_meta_hints, possibly kuzu_queries.count_calls_for_symbol or a small helper for role histogram)
• mcp_v2.py (payload fields passed into hint generation if needed)
• tests/test_mcp_hints.py

Out of scope

• Changing callee_declaring_role build-time semantics (PR-1 / pass3).