MAINT Decompose scorer execution policy and result finalization

@iamhaseebn is already working on this.

Since Aug 22, 2026.

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

`Scorer.score_async` in `pyrit/score/scorer.py` is the central execution path for every scorer and currently combines several distinct policy stages in roughly 121 lines and 27 branches:

- structured-refusal and partial-content substitution;
- validator and role-filter handling;
- error-result skip policy;
- objective inference;
- subclass score execution;
- blocked-scorer and exception policy;
- fallback-score construction;
- score validation;
- ephemeral message-piece foreign-key cleanup;
- persistence to memory.

All of these responsibilities belong at the scorer layer, but keeping their decision matrix in one method makes edge cases difficult to audit and extend. Changes to blocked content, structured refusals, or persistence can unintentionally affect every scorer and downstream attacks such as Crescendo.

#### Describe the solution you'd like

Keep `Scorer.score_async` as the public orchestration entry point, but extract cohesive internal units rather than pass-through wrappers. One possible design is:

1. A typed scoring-input/policy decision that produces the effective message, objective, and skip decision.
2. A narrowly scoped execution/error-policy step around `_score_async`.
3. A result-finalization helper that applies fallback behavior, validates results, clears ephemeral foreign keys, and persists scores.

The refactor must preserve scorer ownership of these policies and should not move decisions into targets, attacks, or memory.

#### Describe alternatives you've considered, if relevant

A new service/facade would add an abstraction without clarifying ownership. Extracting every conditional into a tiny helper would reduce method length but increase navigation and leave the policy matrix implicit. A typed intermediate result is preferred because it makes the allowed states and invariants testable.

#### Additional context

Acceptance and validation should include:

- all scorer unit tests;
- blocked response with and without partial content;
- structured refusal substitution;
- `skip_on_error_result` and role-filter combinations;
- explicit and inferred objectives;
- scorer-owned blocked responses with both raise/fallback policies;
- PyRIT and non-PyRIT exception propagation;
- fallback scores for empty/filtered pieces;
- ephemeral versus persisted message pieces;
- exact memory writes and score validation;
- Crescendo and red-teaming caller tests.

This is a medium-confidence design proposal with high compatibility impact. Please preserve behavior and add matrix-style tests before moving logic.