Check evidence producer polarity before naming public result fields

When exposing an existing verification result through a new API, trace the boolean back to its producer before naming the public field. A stored true value may mean the check passed, while a field named for the detected attack requires the opposite polarity. Plausible synthetic fixtures can preserve the mistake. Add regression cases grounded in the producer's genuine-input and rejected-input semantics, and retain an explicit unavailable result for provider failures. This applies to projections of existing checks; it does not establish the underlying detector's accuracy.

Applies when: an API gives existing verification booleans new names. Keywords: API evidence boolean polarity verification projection regression testing