📝 Update README and docs with new positioning strategy

Summary

Update README, docs, and GitHub description to reflect the new positioning strategy focused on "variable-cost operations" rather than LLM-specific messaging.

Core Positioning

Tagline:

Rate limiting for variable-cost operations

The Pattern:

Estimate → Execute → Reconcile

Why it exists:

Traditional rate limiters require knowing the cost before the request. zae-limiter lets you estimate, execute, then reconcile with the actual usage.

Messaging Hierarchy

Level 1 - Tagline:

Rate limiting for variable-cost operations

Level 2 - The Pattern:

Estimate before, execute, reconcile after. For operations where you don't know the cost upfront.

Level 3 - Examples:

• LLM APIs (token count varies by response)
• Video/audio processing (duration unknown until complete)
• Metered APIs (response size varies)
• Data pipelines (records scanned varies)
• Streaming responses (bytes sent unknown until done)

Level 4 - Technical Features:

• adjust() for post-hoc reconciliation
• Hierarchical limits (user → org → global)
• Multi-dimension limits (RPM + TPM in one call)
• DynamoDB-native (~$1/1M requests)
• Audit logging built-in

Changes Required

1. GitHub Repository Description

Current: (check current)

New: "Rate limiting for variable-cost operations - estimate, execute, reconcile"

2. README.md

Restructure to lead with the pattern:

# zae-limiter

**Rate limiting for variable-cost operations.**

Traditional rate limiters require knowing the cost before the request. 
zae-limiter lets you estimate, execute, then reconcile with actual usage.

## The Pattern

\`\`\`python
async with limiter.acquire(entity_id, limits, consume={"units": estimated}) as lease:
    result = await do_operation()
    await lease.adjust(units=actual - estimated)  # Reconcile
\`\`\`

## Use Cases

- **LLM APIs** - Token count varies by response
- **Video processing** - Duration unknown until complete  
- **Metered APIs** - Response size varies
- **Data pipelines** - Records scanned varies
- **Streaming** - Bytes sent unknown until done

## Features

- \`adjust()\` for post-hoc reconciliation
- Hierarchical limits (user → org → global)
- Multi-dimension (requests + units in one call)
- DynamoDB-native (~$1/1M requests)
- Audit logging built-in

## Quick Start
...
\`\`\`

### 3. Docs Landing Page (docs/index.md)

Lead with problem:
> Building APIs with variable-cost operations? Need to limit usage when you don't know the cost upfront?

### 4. Docs Guide Intro

Update to list multiple examples, not just LLM:
- LLM tokens
- Video processing
- Metered APIs
- Data pipelines
- Streaming responses

### 5. PyPI Description

Mirror the README intro.

### 6. Module Docstring (src/zae_limiter/__init__.py)

Update to reflect new positioning.

## Key Differentiators to Emphasize

| Differentiator | Message |
|----------------|---------|
| `lease.adjust()` | "Reconcile with actual usage after the operation" |
| Variable-cost focus | "Built for operations where cost isn't known upfront" |
| Hierarchical | "Cascade limits from user → org → global" |
| Multi-dimension | "Multiple limits (requests + units) in one call" |
| DynamoDB | "No Redis to manage, ~$1/1M requests" |

## What to De-emphasize

| Feature | Why |
|---------|-----|
| "Token bucket algorithm" | Everyone has this, not differentiating |
| DynamoDB performance | It's slower than Redis, don't highlight |
| CloudFormation | Implementation detail |
| Generic "rate limiting" | Too crowded |

## SEO Keywords to Target

**Primary:**
- "variable cost rate limiting"
- "rate limiter with adjustment"
- "post-hoc rate limiting"
- "DynamoDB rate limiter"

**Secondary:**
- "LLM rate limiting" / "token budget"
- "metered API rate limiting"
- "per-user rate limits Python"

## Acceptance Criteria

- [ ] GitHub repo description updated
- [ ] README restructured with new positioning
- [ ] Docs landing page updated
- [ ] Guide intro lists multiple use cases (not just LLM)
- [ ] PyPI description matches README
- [ ] Module docstring updated
- [ ] Consistent messaging across all touchpoints

## Related

- #147 - "Is zae-limiter right for you?" section
- #148 - Alternatives/comparison page

Start by comparing README.md with the current GitHub description and inspect docs/index.md, the docs guide intro, and src/zae_limiter/init.py. Update each listed touchpoint to use the variable-cost positioning and examples while preserving the documented technical features. Done means the README, docs, PyPI description, module docstring, and repository description are consistent and all acceptance criteria are checked.