Spend limits are reactive and can be exceeded before sandbox cost accrues

[09Catho]

claim_sandbox_creation() calls _policy_violation() before the sandbox's
actual provider rate is known, and _policy_violation() compares only spend
already accrued in the ledger against the configured limit.

That means the cost of the sandbox being created is not part of the admission
decision.

I reproduced this on pristine upstream with a fake provider reporting $50/hr:

hourly/daily limit : $0.01
accrued spend      : $0

create $50/hr pod  : PERMITTED
stored rate        : $50.0/hr

second pod         : PERMITTED

--- 60 seconds later ---

accrued spend      : ~$1.67
third pod          : DENIED (hourly_spend_limit_usd)

The dynamic-rate path itself appears correct: after creation,
runtime.estimate_compute_cost(3600) is written back through
complete_sandbox_creation(), so this isn't a RunPod pricing issue.

The question is about policy semantics: spend limits currently behave as
reactive limits on already-accrued spend rather than preflight limits on new
resource creation.

Is that intentional?

If yes, it may be worth documenting that these limits are soft and can be
exceeded between admission and subsequent accrual checks.

If not, admission would need some notion of projected/reserved cost. That seems
straightforward for statically priced backends, but trickier for providers where
the authoritative rate is only available after provisioning.

Happy to send a regression test / PR once the intended behavior is clear.