clamp billing-cycle resets to the month's last day

[dontlaugh]

A subscription anchored on the 29th, 30th, or 31st gets the wrong metric period in any month with fewer days than the anchor. GetCurrentMetricPeriodStartForCompanyBillingSubscription built the reset with time.Date(now.Year(), now.Month(), periodStart.Day(), …), so "September 31" normalized to October 1, landed in the future, and the code stepped back to September 1 instead of August 31; usage from the tail of the previous cycle then counted against the new one. GetNextMetricPeriodStartForSubscription had the identical construction.

Both now place the anniversary inside the target month, clamped to its last day, and move to the adjacent month by recomputing the anniversary there rather than with AddDate, so an anchor on the 31st resets on the 30th in a 30-day month and on the 28th or 29th in February.

The two functions take the evaluation instant through unexported …At variants; the public functions pass time.Now(). That lets the tests drive the clock: a sweep of every anchor day across two years checks both functions day by day against an independent oracle (latest reset at or before now, earliest after, one calendar month apart, day clamped to the month), every anchor day in every month of leap, non-leap, and century years agrees with the oracle, the reset instant and the nanosecond before it fall on opposite sides, and the period-end cap, future starts, and the no-subscription fallback are pinned. The clock-based tests that run against the real date stay too.

Surfaced by TestMetricPeriodWindow in schematic-api, which anchored a subscription ten days before now and failed for all of 2026-09-10 UTC (since re-anchored on the 10th in schematic-api #8318, which unblocks CI but leaves this bug in place).

The version.go govet finding from task lint is pre-existing and unrelated.