[Docs/SDK] Define and enforce `payment.agent_recurrence` frequency semantics

[zesttec]

Problem Description

AP2 v0.2 requires recurring Payment Mandate presentations to be “sufficiently separated in time” according to frequency. However, the frequency values do not have interoperable time semantics. It is unclear whether values such as DAILY and MONTHLY represent rolling intervals or calendar periods, which event supplies the reference timestamp, and which timezone and boundary rules apply. ([documentation], [schema])

The current Python AgentRecurrenceEvaluator checks only total_uses against max_occurrences. It does not read frequency or last_used_date. The existing period helper is not called and does not explicitly implement BIWEEKLY or QUARTERLY. ([implementation])

The tests cover occurrence counts and missing context, but do not test frequency boundaries. In the current DAILY under-limit test, last_used_date is set to the current time and evaluation still succeeds. (test)

Potential impact

This is a specification and SDK correctness issue. Implementations may disagree about whether a recurring payment is permitted at a particular time boundary. An SDK caller relying on the current evaluator may not receive a violation for a presentation that is earlier than the intended cadence.

Suggested fix

• define each frequency as a rolling interval or calendar rule, including its reference event, timezone, DST and boundary behavior;
• clarify when an occurrence is counted and what an absent max_occurrences means;
• evaluate every supported frequency using trusted context, or reject unsupported frequency semantics; and
• add same-period, next-period and boundary tests for every enum value.

Related issues

Adjacent threads such as Issue #207 and Discussions #258 and #262 address cumulative budget state or consume-once behavior, not recurrence time semantics.