FEAT Preserve multiple labeled true/false verdicts from one scorer call

[immu4989]

Is your feature request related to a problem? Please describe.

Some classifier endpoints return several independent verdicts from one inference. WildGuard is a concrete example: one request reports whether the user request is harmful, whether the response is a refusal, and whether the response is harmful.

MessageTrueFalseScorer currently reduces piece-level results to one boolean. In #2302, WildGuardScorer therefore selects one label as the Score value and preserves the other two as flattened score_metadata. This avoids repeated model calls, but the additional verdicts are not independently queryable, composable, or evaluable through the normal score APIs. Creating three scorer instances would expose three scores but repeat the same inference three times.

There is already a useful precedent on the float side: AzureContentFilterScorer can return one Score per harm category from a single service response. The true/false family does not have an equivalent category-preserving path because its base implementation aggregates every returned boolean together.

Describe the solution you'd like

Add an opt-in way for a true/false scorer to return multiple labeled verdicts from one scoring operation.

Desired behavior:

• One target call may produce one Score per labeled verdict.
• Each verdict is independently persisted and addressable using a stable label/category.
• For a message containing several supported pieces, aggregation happens within each label, never across unrelated labels.
• Existing single-verdict MessageTrueFalseScorer behavior remains unchanged.
• Attack paths that require one objective verdict use an explicit selector/projection rather than relying on list order.
• Persistence, composition, threshold/wrapper behavior, batch scoring, and evaluation semantics are covered by focused tests.

I would prefer to stage this:

1. Add the core category-preserving contract and aggregation behavior using a synthetic test scorer.
2. After FEAT Add a WildGuard scorer following the LlamaGuard and ShieldGemma pattern #2302 lands, optionally migrate WildGuard while retaining its current selected-label API as a compatibility projection.

Open design questions

1. Should this be a separate true/false scorer base, or an aggregation mode on MessageTrueFalseScorer?
2. Is score_category the right stable identity for each verdict, or should the score model carry a dedicated output label?
3. Should selecting the objective verdict be owned by the scorer, a generic wrapper, or AttackScoringConfig?

Opening this to settle the representation before writing code.

Alternatives considered

• Keep secondary verdicts only in score_metadata: efficient, but they remain outside normal score querying, composition, and evaluation.
• Instantiate one scorer per label: fits the current API, but performs the same expensive model inference repeatedly.
• Make WildGuard a one-off multi-score implementation: possible, but would leave true/false aggregation and downstream single-score assumptions implicit rather than establishing a reusable contract.

Additional context

• WildGuard implementation: FEAT Add a WildGuard scorer following the LlamaGuard and ShieldGemma pattern #2302
• Existing multi-category float precedent: AzureContentFilterScorer
• Recent scorer contract work: FEAT: Refactoring score model (phase 2) #2491 and FEAT: Policy Scorer Compatibility (phase 2.5) #2518