Expand supported AsyncMlb endpoint coverage

[Mattsface]

Parent: #297
Depends on: #303, #304

Goal

Expand AsyncMlb beyond the initial vertical slice in a controlled, reviewable way while preserving sync/async behavioral parity.

Scope

• Group related endpoints into manageable implementation batches
• Reuse shared parsing/model-construction helpers where practical
• Add deterministic tests for each newly supported async endpoint group
• Extend sync/async parity coverage as support expands
• Track unsupported endpoints explicitly until implemented

Contract requirements from #298

Every newly supported async endpoint must inherit the established v1.1 contract rather than defining its own transport behavior:

• Same public endpoint name and arguments as sync where possible
• Same existing domain model return types
• Same None, [], and {} behavior
• Same endpoint-specific 404 semantics
• Same strict/default HTTP behavior and strict_http=False compatibility behavior
• Same public exception hierarchy and structured HTTP error semantics
• Same timeout, transport, and decode behavior
• Same library/caller client ownership rules
• Same cancellation propagation rules
• Same User-Agent behavior for library-owned transport
• Same caller-controlled concurrency model
• No hidden endpoint fan-out/background work unless a future endpoint-specific design explicitly justifies and documents it

New endpoint implementations should use shared parsing/model logic rather than creating async-only copies.

Constraints

• Do not imply full async parity before it exists
• Avoid a single giant port of every Mlb method
• Do not change synchronous public behavior to make async implementation easier
• Keep each endpoint group small enough for focused review
• Do not weaken or silently diverge from Define the v1.1 async API and transport contract #298 as coverage expands

Acceptance criteria

• Async endpoint support expands beyond the initial vertical slice
• Supported async methods are clearly documented
• Unsupported methods are not presented as supported
• New endpoints return the same domain model types as sync equivalents
• New endpoint groups preserve Define the v1.1 async API and transport contract #298 HTTP/error/empty-result semantics
• New endpoint groups preserve ownership/cancellation/concurrency rules where applicable
• New endpoint groups have deterministic tests and parity coverage
• Existing synchronous API remains unchanged

Refs #297
Contract: #298