feat: price a run from a versioned rate table - #33

No actionable issues found.

The change looks sound. The pricing logic is cleanly separated into a dedicated priceRunFromRateTable flow that resolves the effective rate via resolveEffectiveRate and applies it through a standard priceRun step, which keeps responsibilities clear and makes the new path easy to reason about and test. Versioning via effectiveFrom / effectiveTo ranges on RateTableVersion is handled consistently across the resolver and the storage query, so lookups respect the run's pricedAt boundary without ad-hoc branching. Error handling around missing rates and invalid date ranges is explicit (NoRateForDateError, InvalidRateVersionRangeError), which is the right shape for callers that need to react differently to "no rate exists" versus "data is misconfigured," and the error wrapping through Result preserves context for debugging. The repository query parameters mirror the domain inputs one-for-one, and the integration with priceRun reuses existing validation and rounding rather than duplicating it, reducing drift risk between the versioned and non-versioned pricing paths. Overall the design choice to keep rate selection as a distinct pre-step rather than entangling it with pricing arithmetic is a good one and should make future additions (e.g. tiered or jurisdiction-specific rates) straightforward to layer on.