refactor: simplify core boundaries for seasons and scoring

[adrunkhuman]

Goal

Simplify the internal boundaries that block v3 features: seasons, per-season scoring rules, and reliable recalculation.

This is no longer a parked refactor-only ticket. It is the architecture foundation for v3.0.0.

Direction

• keep the bot small and practical
• prefer removing duplicated workflow logic over adding abstraction
• keep user-facing behavior stable until the season/scoring issues intentionally change it
• avoid framework-style or enterprise patterns
• make the important business rules live in obvious service-level code, not scattered Discord views or repository helpers

Current problems to address

• scoring and recalculation logic are duplicated across service and repository paths
• prediction submission rules are still partly split across handlers, commands, and DB helpers
• repository code owns some workflow behavior that should live above persistence
• admin panel code repeats state mutation and rerender patterns
• too many dict-shaped contracts make season/scoring changes risky

Expected v3 outcome

• one scoring/recalculation path used by normal calculate, result correction, prediction replacement, waiver toggles, and partial approval/rejection
• repositories focused on storage and transactions
• Discord UI code calls service methods instead of owning business decisions
• a few typed payloads where they clarify season/scoring/prediction contracts
• smaller admin-panel modules and focused tests before feature work lands

Non-goals

• no ORM migration
• no plugin system
• no event bus
• no giant state-machine framework
• no speculative multi-league-per-server architecture
• no broad config framework

Related v3 work

This issue should be completed through focused slices in the v3.0.0 milestone, especially the scoring/recalculation service, season model, scoring rules, and admin-panel decomposition issues.

[adrunkhuman]

Reframed for v3.0.0 as the architecture foundation for seasons and scoring, not a generic cleanup bucket.

The most important first slice is #216, because per-season scoring rules are unsafe while normal calculation and recalculation paths can diverge. Admin-panel decomposition remains covered by #192 and #193.