Failure backoff for dispatch, keyed on dedupe key

[FreshlyBrewedCode]

What to build

Optional follow-up to #19, deliberately kept out of that epic — schedules and the Ready sweep port ship without it.

The retired dispatcher backed off after failures: a failing issue waited before being retried, doubling per consecutive failure up to a 24h cap, derived from the persisted run history rather than a separate retry-state file that could drift. That behaviour was welded to one specific input field. Its natural generalization is the dedupe key from #15 — history joins on the key, so any wrapper that dispatches with a stable key gets backoff without doing anything.

Backoff stays in the runtime rather than moving into workflow bodies. A wrapper would otherwise need to read past run history, which the workflow context has no affordance for, and every wrapper would end up reimplementing the same window arithmetic.

Keep it minimal: the existing base/cap/doubling behaviour, keyed differently. Not a scheduling policy engine.

Acceptance criteria

• A dispatch whose dedupe key's most recent run failed is refused until its backoff window has elapsed
• The window doubles per consecutive failure from a configurable base up to a configurable cap
• A successful or cancelled run clears the failure streak
• The window is derived from the persisted run history, with no second store that can drift from it
• A refusal is visible: the caller gets an error naming the key and when it next becomes eligible
• Runs started without a dedupe key are never backed off

Blocked by

• Dedupe keys on run start #15