v10.1.1

• Fixes the SQLite backends leaking a reservation from
  snapshot_state()["in_flight_reservations"] when a refund failed closed with
  UnknownReservationError — for example after the acquire marker expired.
  The reservation stayed counted as in flight for the life of the limiter, so a
  long-running process could drift toward its in-flight cap and eventually raise
  CardinalityLimitExceededError on healthy acquires. The Redis backends
  already released the reservation in this case; SQLite now matches them.
  Capacity accounting is unaffected — the refund still fails closed and credits
  nothing.

• Fixes the memory backends never finalizing a reservation whose buckets all
  disappeared in a callable-config metric-set change. Such a refund returned
  early — before releasing the reservation's backend acquire state or recording
  its dedup entry — so the backend kept treating it as acquired for the life of
  the process. The refund is now finalized on that path under ordinary warning
  handling. Capacity accounting is unchanged: there are no surviving buckets to
  credit.

  One pre-existing limitation is unchanged by this fix: that refund path emits a
  Refund dropped RuntimeWarning before it reaches the backend, so a caller
  running with warnings promoted to errors (-W error) still raises there and
  still leaves the reservation live. Reordering the notification after
  finalization is tracked separately.