feat(ratelimit): in-memory token bucket for pure-Pebble path

[osvaldoandrade]

Summary

The pure-Pebble path used a `noopLimiter` that allowed every request even when rate limits were configured. Silent foot-gun: operators saw the YAML knobs (`producer.requestsPerMinute`, `burstSize`, …) and trusted them; runtime ignored them.

This PR ships an in-process token-bucket limiter for the pure-Pebble path. Configuration now actually takes effect.

Design

• Per-node enforcement: in a cluster of N codeq nodes, the effective per-(scope, subject) ceiling is N × `requestsPerMinute`. No external coordinator; state is in-process memory.
• Trade-off: dragging a Redis dep into the embedded path would defeat the purpose of "100% Pebble". Per-node enforcement is the right knob — legitimate clients don't get rebalanced across nodes mid-burst, and the alternative (cluster-wide via raft) would add a write per Allow which is much worse than the limit it's protecting.
• Concurrency: top-level RWMutex protects the buckets map; each bucket has its own `sync.Mutex` for refill + decrement. Typical workloads with one bucket per JWT subject never contend.
• GC: janitor reaps buckets idle > 10 min so the map stays bounded under per-token churn.

What landed

• `internal/ratelimit/inmemory.go`: `InMemoryLimiter` with the standard `Limiter` interface.
• `pkg/app/application.go`: when `cfg.PersistenceProvider=="pebble"` wire `NewInMemoryLimiter()` instead of the noop.
• `docs/14-configuration.md` "Rate limiting" section corrected — the "no-op in pure-Pebble" claim was wrong post-merge.

Test plan

• 8 unit tests for InMemoryLimiter (disabled bucket, burst → block → refill, isolation per subject + per scope, capacity reconfig, concurrent stress, janitor)
• `go test ./pkg/app` passes — no regressions wiring the new limiter into the Application
• Manual: set `rateLimit.producer.requestsPerMinute: 6` + `burstSize: 3` on a single-node pebble deploy; verify the 4th request in a burst returns 429 with `Retry-After`

🤖 Generated with Claude Code