✨ Support usage-milestone-based rate limit ramp-up

Problem or Use Case

New entities (users, API keys) may need to demonstrate legitimate usage patterns before unlocking higher rate limits. Time-based ramp-up (#222) assumes trust increases with account age, but this can be gamed by attackers who create accounts and wait.

Usage-milestone-based limits unlock higher capacity based on demonstrated good behavior:

1. Abuse prevention - Attackers must invest real usage before getting high limits
2. Trust building - Limits increase as users prove legitimate usage patterns
3. Gaming/social platforms - New accounts can't immediately flood systems
4. Gradual onboarding - Users naturally unlock more capacity as they use the service

Proposed Solution

Add milestone-based ramp-up configuration to limits:

Limit.per_minute(
    "rpm",
    capacity=1000,  # Target capacity
    ramp_up=RampConfig(
        initial=100,
        milestones=[
            {"total_requests": 1000, "capacity": 250},    # After 1K requests
            {"total_requests": 10000, "capacity": 500},   # After 10K requests
            {"total_requests": 100000, "capacity": 1000}, # After 100K requests
        ],
    ),
)

Behavior

Implementation Notes

• Requires tracking cumulative request count per entity
• Could leverage total_consumed_milli counter or usage snapshots
• At acquire-time, look up entity's total usage and find applicable milestone
• Milestones are one-way (don't reduce limits if usage decreases)

Success Criteria

• Define usage milestones on limits
• Track cumulative usage per entity
• Effective limit calculated from current milestone tier
• CLI can display entity's current milestone and progress to next
• Audit logs capture milestone transitions

Open Questions

• Metric for milestones - Total requests? Total tokens? Configurable?
• Milestone scope - Per-resource or aggregate across all resources?
• Reset behavior - Should milestones ever reset (e.g., monthly)?
• Interaction with other dynamic limits - How do milestones combine with time-based (#222) or utilization-based (#223)?

Alternatives Considered

• Time-based ramp-up - Covered by #222. Simpler but can be gamed by waiting.
• Manual tier upgrades via webhooks - Covered by #224. More flexible but requires external logic.

Related Work

• #222 - Time-based dynamic rate limits (includes time-based ramp-up)
• #223 - Utilization-based adaptive rate limits
• #224 - Event-driven webhooks (alternative approach)
• Usage snapshots provide cumulative usage data
• Part of the Dynamic Rate Limits initiative

Start by reviewing the Limit.per_minute configuration, usage snapshots, and the total_consumed_milli counter mentioned in the issue. Resolve the open questions about milestone metrics, scope, resets, and interactions with other dynamic limits; done means all listed success criteria are implemented, including CLI progress and audit-log transitions.