fix(purchase): recheck the step cap when an approved or scheduled step fires #1882

Problem

The step commitment cap (plan cap, and since #1872 the per-group caps of a bound plan) is checked when a step is attached to a plan, at the scheduler claim of an auto-purchase step (recheckStepCap), and when an email-token approval is processed. A step that is already approved or scheduled is not rechecked when it fires (internal/purchase/scheduled_fire.go, reaper.go, claim.go).

So a step that was approved under the old limits, or approved by a path that checks only its own constraints (a session approver, the admin API key), can still execute over a cap that has since been lowered or a group that was later widened or disabled. This is true of the plan cap today; #1872 extends the same exposure to group caps.

Found in the review of #1872 (reported there as pre-existing, not a regression).

Proposal

Re-run CheckStepCommitmentCap against the current plan (including the bound-group checks) when an approved or scheduled step is claimed for execution, and refuse with the cap error as the scheduler claim already does for auto-purchase steps. Add tests for a plan cap lowered after approval and a group cap lowered or a group disabled after approval, in the scheduled-fire and reaper paths. The check must run before any provider call and must not stamp no_submission incorrectly: a refusal here happens before submission, so it should use the existing before-submission refusal class.