Re-evaluate Blazor ComponentBase structure for testability and code splitting

[jschick04]

Context

LogTablePane.razor.cs is 812 LOC with 6 responsibility groups identified during the architecture alignment audit:

1. Column management — reorder, resize, width calculation, ordering, header menus
2. Keyboard/focus/scroll — key handlers, focus tracking, scroll coordination
3. Selection state — dispatch, sort coordination, multi-select
4. Context menu / event-field menus — menu builders, action handlers
5. CSS/highlight/level styling — conditional classes, highlight application
6. Filter integration — filter-from-selection, filter dispatch

Problem

Blazor ComponentBase code-behinds are inherently hard to split:

• Lifecycle methods (OnAfterRenderAsync, OnParametersSet) coordinate across all groups
• StateHasChanged calls are scattered throughout
• Partial classes fragment lifecycle without reducing coupling
• Component parameters create cascading dependencies between groups

Goals

• Testability: Expand component testing coverage. Individual concerns (column logic, keyboard handling, menu building) should be independently testable.
• Less duplicate code: Identify patterns across components that could be extracted into shared services or base behaviors.
• Better ComponentBase patterns: Evaluate industry approaches for large Blazor components:
  • Extract helper services injected via DI (column manager, keyboard handler, menu builder)
  • Composition via child components with parameter cascading
  • Render fragments + partial template splitting
  • bUnit testing strategies for extracted services vs full component tests

Panel findings

• 2/3 reviewers recommended deferring the split (Blazor pitfalls, not actively modified)
• 1/3 included it in remediation sequence
• All agreed it passes the responsibility-group test but Blazor-specific constraints make the split harder than a regular service

Acceptance criteria

• Survey current component testing patterns in the solution
• Evaluate splitting approaches (DI services vs child components vs render fragments)
• Prototype the most promising approach on LogTablePane
• Document the chosen pattern for future component decompositions
• Assess impact on existing bUnit tests