v0.2.0

Dependency alignment: @pegma/storage-core advances from 0.3.0 to 0.4.0 (and the @pegma/storage-azure-tables conformance dev dependency to 0.4.0), matching the pin used by webhooks, mail, and identity so host dependency trees resolve a single storage-core. The release gate's reviewed pin advances in lockstep. No behavioural or public API change; hosts must now supply a storage-core 0.4.0 Store, which is the breaking composition change that moves the version to 0.2.0.

v0.1.1

Security patch resolving the actionable findings in docs/securityscan.md. Memory tier only; the durable tier is unchanged.

• Bounded key tracking. The memory tier previously grew without bound inside one window: after the first prune, no reclaim could run for a full window, so a client rotating keys added an entry per allowed check. It now tracks at most 10,000 keys and fails closed with retryAfter for untracked keys at the cap. Tracked keys keep their counts and are never evicted, so a spray can neither exhaust host memory nor reset another subject's window, and over-limit refusals stay read-only.
• Bounded key length. The memory tier retains the raw key, so it now rejects keys over 512 UTF-16 code units, checked before the well-formedness scan walks the string. The durable tier hashes keys to fixed-length identifiers and still accepts keys of any length.
• Prompt reclaim. The reclaim scan is aimed at the moment the earliest tracked entry becomes reclaimable, with a 50 ms floor between scans, so capacity returns promptly after a spray ages out instead of up to windowMs / 8 later.

The azurite devDependency advisories were evaluated and disputed: they reach neither the published tarball nor the test harness, and no upstream remediation exists. See docs/securityscan.md for the full dispositions.

v0.1.0

First advertised release of @pegma/rate-limit: explicit in-memory sliding-window and durable fixed-window tiers, with fail-closed storage behavior and bounded durable identifiers.