feat(billing): Billing engine v2 date services

[brunomiguelpinto]

Contract billing needs consistent dates across rate changes, phase overrides and long billing histories. This adds a rate-card schedule that produces billable segments and can resume near a requested date without walking every historical cycle.

Behaviour

• CycleWalker owns traversal and resume. It stops at rate and phase transitions, recalculates the calendar when the interval changes, and reuses calendars between calls. Walking the complete history remains supported.
• Schedule splits cycles at rate changes and assigns each priced segment its own billing date: start for advance, end for arrears. Unpriced windows still consume cycle indices.
• Proration uses customer-local calendar days and the containing interval. Schedule windows have exclusive ends; BillingSegment.inclusive_end and .exclusive_end convert stored boundaries.
• BuildScheduleService reads ContractRateCard, resolves ordered rates and card or plan phases, and resumes from that attachment's latest persisted cycle. The last cycle is intentionally returned again, so the writer must deduplicate persisted segments. Separate attachments do not share billing history.
• Card effective and end dates use the customer's timezone. An inclusive card end date covers the whole final day; an earlier contract end or explicit termination instant takes precedence.
• Contract materialization seeds the initial billing clock from the schedule, including backdated contracts and phase interval overrides.

Public schedule API

Method	Purpose
segments_due_by(timestamp)	Return priced segments due by that instant.
next_billing_at(after:)	Find the next billing instant strictly after the given time.
billing_at_covering(timestamp)	Find the billing date of the segment being served, or the next priced segment.
consumed_ratio(segment:, at:)	Measure consumption against the original billed segment.

Integration with main

This PR is based directly on main and contains only the date engine and its contract integration. It uses the existing contract models and billing-segment table. Existing migrations, Ruby 4.0.6 and dependencies are unchanged.

A separate migration removes the unused pricing_unit_id and rate_card_rate_id indexes from billing_segments, with concurrent operations and a reversible rollback.

The invoice writer and processor are outside this PR.

Validation

• 422 examples passed with Ruby 4.0.6 in a temporary API container and isolated database: 113 integration/model examples and 309 date/walker/resume examples.
• Coverage includes month ends, leap years, DST, rate and phase transitions, unpriced periods, termination, persisted history, contract materialization and equivalence between full and resumed walks.
• RuboCop: 32 files, no offenses.
• Migration up/down/up verified with an existing billing segment; both indexes were restored on rollback and the row was unchanged.

[brunomiguelpinto]

Read it end to end. The pure layer is the strongest part — Interval, Calendar and Segments have no dependencies, and having the QA scenarios pinned as value tables means an expectation can be checked against the plan rather than argued about. Three things I'd want addressed before this lands, one of them structural.

[annvelents]

LGTM! 👏 ⭐ 🦸 🪨 🐐 🤘 🎊 🥇