Add fixed-window counter rate limiting

[rapind]

Summary

• Adds glimit/window module with fixed-window counters and layered windows
• Uses ETS with atomic update_counter for lock-free, concurrent operation
• Unlike the token bucket (which smoothly refills tokens), fixed-window counters
  divide time into discrete windows and count requests. Ideal for:
  • Login/verification attempt limiting (e.g. 5 attempts per 15 minutes)
  • API rate limiting with clear reset boundaries
  • Layered limits (e.g. 1/min + 3/15min + 10/hour + 20/day)
• 11 new tests, README updated with documentation

Note on storage

The window module uses its own dedicated ETS table with atomic update_counter
operations. It does not go through the pluggable bucket.Store interface. This
is intentional since fixed-window counters are typically a single-node pattern
and benefit from the atomicity guarantees of ETS. A pluggable store interface
for window counters could be added in the future if there's demand for
distributed fixed-window rate limiting.

Usage

let limiter = window.new()

let windows = [
  window.Window(window_seconds: 60, max_count: 1),
  window.Window(window_seconds: 900, max_count: 3),
  window.Window(window_seconds: 3600, max_count: 10),
]

case window.check(limiter, email, windows, now_seconds) {
  Ok(Nil) -> // allowed
  Error(window.Denied(retry_after)) -> // denied
}

Depends on

• Add ETS-backed storage backend #29 (ETS storage backend) must be merged first

Test plan

• All 11 new window tests pass
• All 88 tests pass (existing + ETS store + window)

[rapind]

Updated to reflect that ETS is the new default.