✨ Add scoped TTL for auto-created entities

Problem or Use Case

This is Phase 3 of entity lifecycle management from #234.

Entities created implicitly via first acquire() (without explicit create_entity()) represent transient usage patterns and can safely expire. However, entities explicitly created via create_entity() represent intentional configuration and should persist indefinitely.

Risk of Naive TTL

# Admin configures VIP customer with 10x limits
await limiter.set_limits("enterprise-client", limits=[Limit.rpm(100000)])

# Customer goes on 3-month hiatus...
# Naive TTL deletes config after 90 days

# Customer returns → gets default limits (100 rpm instead of 100,000)

Proposed Solution

Distinguish between auto-created and explicitly-created entities. Apply TTL only to auto-created entities.

Acceptance Criteria

• Implicit entity creation (via acquire()) is distinguishable from explicit (create_entity())
• entity_ttl_days parameter controls TTL for auto-created entities (default: disabled)
• Explicitly-created entities never have TTL regardless of entity_ttl_days setting
• Existing entities (pre-upgrade) treated as explicitly-created (backward compatible)
• Unit tests cover both creation paths and TTL behavior

Parent Issue

Implements Phase 3 of #234.

Start by tracing the implicit entity path through acquire() and the explicit path through create_entity(), then inspect the unit-test structure for entity persistence and TTL behavior. Implement the distinction and entity_ttl_days handling described in the acceptance criteria, and add tests showing TTL for implicit entities, no TTL for explicit or pre-upgrade entities, and the disabled default.