tip-1011: add periodAnchor for calendar-aligned period resets

[snario]

Proposal

Stacked on #2632. Adds periodAnchor to TokenLimit for calendar-aligned period resets.

Problem

The current periodic limit reset is relative: periodEnd advances from the last reset by whole multiples of period. This prevents drift but doesn't guarantee alignment to calendar boundaries. A monthly limit that starts mid-March will always reset mid-month.

This is insufficient for use cases that need deterministic calendar resets — e.g., daily limits that reset at midnight UTC, or monthly limits that reset on the 1st.

Solution

Add periodAnchor (uint64) to TokenLimit. When nonzero, it's a fixed UTC timestamp that periodEnd snaps to:

periodAnchor = 1740787200   // 2025-03-01T00:00:00Z
period       = 2592000      // 30 days
// → resets always land on the 1st, regardless of when the last tx was

Reset logic with anchor:

elapsed = block.timestamp - periodAnchor
periodsElapsed = elapsed / period + 1
periodEnd = periodAnchor + (periodsElapsed * period)

A late transaction on day 3 of a monthly period still resets to the 1st of next month, not "now + 30 days."

periodAnchor = 0 (default) preserves current relative behavior — fully backward compatible.

Changes

• New periodAnchor field on TokenLimit struct
• Anchor-aware branch in verifyAndUpdateSpending pseudocode
• New storage slot: spending_limit_period_anchor[key][token]
• RLP encoding: V3 = 6-field TokenLimit (V1/V2 decode with periodAnchor=0)
• New test cases: anchored resets, drift resistance, V2→V3 decoding