Deny once the overage cap is spent

[cbrady]

Follow-up to #30, which added the overage opt-in but had no ceiling: enabled meant the balance stopped gating the credit check entirely.

The cap moves the floor rather than removing it. With overage on, the balance may run down to -cap and the check denies beyond that — the same hard stop an exhausted balance gives with overage off. An absent cap stays uncapped, which is the behaviour #30 shipped.

Company.CreditOverageCaps is keyed by billing credit ID, like CreditBalances and CreditOverageEnabled, and only means anything where the latter is true.

This is what the acceptance review asked for: the API previously precomputed "cap reached" and flipped the overage flag off, which put the decision in two places and meant the engine inherited whatever the payload was built with. Now the engine answers it at check time.

Five subtests cover inside the cap, exactly at it, past it, a cap on a different credit not leaking, and no cap meaning uncapped. rulesengine-rust carries the identical change and mirrors these cases one for one, since the two must agree (SCHY-515).

[bpapillon]

How confident are we in our serialization's ability to distinguish "no overage configuration" (meaning credit checks gate at 0 balance) from a present-but-null configuration (meaning don't gate credit checks)? This would probably live in the other repo, but I wonder if we have tests to ensure this is bulletproof, since it seems like a possible footgun with major repercussions

[bpapillon]

I think we need to take into account our cost/quantity options (blocks below). We could refactor everything here into a function that just returns a cost:

	// Precedence on credit-balance conditions, most specific first. No
	// options supplied falls through to the legacy single-unit check.
	//   1. creditCost[credit_id]: caller-supplied per-call cost in credits;
	//      gate on balance >= cost.
	//   2. eventUsage, when its event_subtype matches the condition's:
	//      simulated quantity for this specific event; gate on
	//      balance >= quantity × consumption_rate.
	//   3. usage: generic quantity (no event disambiguation); gate on
	//      balance >= quantity × consumption_rate.
	//   4. Legacy: balance >= consumption_rate (single unit).
	if cost, ok := scope.creditCost[*condition.CreditID]; ok {
		return creditBalance >= cost, nil
	}

	if eu := scope.eventUsage; eu != nil && condition.EventSubtype != nil &&
		eu.eventSubtype == *condition.EventSubtype && eu.quantity > 0 {
		return creditBalance >= float64(eu.quantity)*consumptionRate, nil
	}

	if scope.usage != nil && *scope.usage > 0 {
		return creditBalance >= float64(*scope.usage)*consumptionRate, nil
	}

Then, we check for overage configuration and, if present and unlimited, simply return open (since we would never gate someone in this situation, they are free to run up as large of a negative balance as they like). Set a "cap" from that as well, and then do a comparison like creditBalance + cap >= cost (where cap would just be 0 in the case that no overage configuration exists).