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

Nobody has claimed this yet.

#### 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 #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: #2302
- Existing multi-category float precedent: `AzureContentFilterScorer`
- Recent scorer contract work: #2491 and #2518

Start with MessageTrueFalseScorer and compare its aggregation and score behavior with the multi-category AzureContentFilterScorer precedent. Review the scorer contract work in #2491 and #2518, then the WildGuard context in #2302. Done should establish an agreed reusable representation, preserve single-verdict behavior, and cover persistence, composition, wrappers, batching, and evaluation with focused tests.

Written by the indexing model from the issue text.