Report on rejected positions to identify vague/generic positions

Building on feedback from @wolfgang8741: use the rejection data we already capture to surface vague/generic positions and the classes they share.

Context

Rejections are already stored — rejecting a property appends an Evaluation(is_accepted = false) linked to the Property (which references the position QID via entity_id). No new capture mechanism is needed.

Task

Build/run reporting against the prod DB to surface:

• Most frequently rejected positions (with rejection rate, not just raw counts, and a min-volume guard)
• Shared classes in the P279 subclass tree those rejected positions funnel up to

The interesting output is the mid-level ancestor classes with high coverage — those are candidates to review and add to Position._hierarchy_ignore (which already excludes things like occupation, historical position, award).

Reference SPARQL from the discussion: ~35% of the 242k position-like items in Wikidata lack a P17 country — possibly a separate follow-up.

cc @wolfgang8741

Start by tracing the existing Evaluation and Property records that store rejected positions, then inspect Position._hierarchy_ignore and the available production database reporting or query entry points. Done means reporting the most-rejected positions with rejection rates and a minimum-volume guard, plus shared mid-level P279 ancestors with high coverage.