v4.2.0

Bug fixes

• The Kernel extension methods (require "retriable/core_ext/kernel") are now
  private, matching idiomatic Kernel helpers like puts and rand.
  Previously retriable and retriable_with_context were public instance
  methods, so they leaked onto every object's public API and could be invoked
  with an explicit receiver (e.g. "foo".retriable { ... }). They remain
  callable in the documented receiver-less form.
  (#146)
• Retriable.with_context (and Kernel#retriable_with_context) now raises
  ArgumentError when called without a block, matching with_override.
  Previously a missing block was silently ignored: the call returned nil and
  the intended block never ran, hiding a caller bug. Behavior change: code that
  relied on the silent no-op will now raise.
• Config#validate! now validates the structure of each entry in contexts,
  so configured contexts are checked on every Retriable.retriable/
  with_context call rather than only when a given context is first used. A
  context whose options contain an unknown key (including a nested contexts
  key) now raises ArgumentError, "<key> is not a valid option", matching the
  with_override path. Non-Hash contexts and non-Hash per-context values
  remain leniently treated as empty options (no behavior change). Option
  values are still validated lazily at retry time, unchanged.

Docs

• Document that on_retry receives next_interval: nil on the final rescued
  attempt, when Retriable is about to give up because tries are exhausted.
  on_retry still fires before on_give_up (unchanged behavior); the nil
  contract is now called out in the on_retry documentation so handlers guard
  arithmetic or logging on next_interval.

Performance

• Config#initialize no longer allocates a throwaway ExponentialBackoff (and
  runs its redundant validate!) just to read default values. Defaults now live
  in a frozen ExponentialBackoff::DEFAULTS constant, removing an allocation and
  redundant validation from the retriable hot path.
  (#149)