MAINT Extract scenario-history aggregate queries and record construction #2769

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

MemoryInterface.get_scenario_history_aggregates() and _build_scenario_history_aggregate_statement() combine SQL aggregation, retry/error accounting, latest-attempt selection, auxiliary name lookup, and typed aggregate-record construction. After page retrieval and attempt-to-work-unit matching have been extracted, these are the remaining core history-query responsibilities in the general memory interface.

This is M3 of three scenario-history extraction steps. Not ready yet: depends on #2768, after #2766. Wait for those boundaries to land, then move aggregation into the same internal query module and reassess readiness before adding help wanted.

Describe the solution you'd like

Extract history aggregate statement construction, execution, and row-to-ScenarioHistoryAggregate conversion. Use the matching logic from #2768 rather than duplicating it, and retain the public MemoryInterface.get_scenario_history_aggregates() method as a delegate.

• Preserve grouping by logical work unit, the existing latest-attempt ordering, and all success/completion/error/retry arithmetic.
• Keep aggregation database-side, with compact result rows and the existing backend-specific expression hooks.
• Preserve empty/default records for requested runs with no matching attempts and the existing sorted attack-name output.
• Finish wiring the page method from MAINT Extract scenario-history page queries from MemoryInterface #2766 through the cohesive internal history-query implementation without changing its return shape.
• Keep legacy/unusable-plan handling and caller policy in their existing layers. Do not redesign the backend service or GUI.

Acceptance criteria:

• Public signatures and typed return values remain unchanged.
• Runs with no attempts retain their zero/default aggregates; empty input is handled as before.
• Repeated attempts, internal retries, error attempts, and transitions between success/error outcomes produce exactly the existing counters.
• Tied timestamps retain the ID tiebreaker; latest timestamps, sorted attack names, and mixed planned/legacy results remain unchanged.
• Runs outside a usable plan keep existing fallback behavior, while unmatched planned attempts remain excluded from counters.
• No full result-object hydration, Python-side replacement of SQL aggregation, or new per-run/per-attempt query loop is introduced.
• Existing memory and backend history coverage exercises the final delegated path and guards database portability.

Describe alternatives you've considered, if relevant

Do not combine this with new counter semantics, a schema migration, or broad extraction of all scenario persistence methods. Do not make a separate service for each extraction step. The intended result is one cohesive private query component reached through the existing memory API.

Additional context

Starting points: pyrit/memory/memory_interface.py, get_scenario_history_aggregates, _build_scenario_history_aggregate_statement, and the page entry point. Coverage: tests/unit/memory/memory_interface/test_interface_scenario_history.py and tests/unit/backend/test_scenario_run_service.py.

Series: #2766 (history pages), #2768 (attempt matching), then this issue (aggregate queries/records). Follow doc/code/framework.md and the applicable database, Python, and test instructions. Memory owns retrieval and database aggregation here, not scenario execution, scoring decisions, or presentation.