fix(gateway): move the budget counter at charge time, reconcile as a floor

[marcorivm]

Addresses the first of the three design comments from #8's review. 2 files, ~90 lines. Stacked on #27.

First, a correction to the review comment

The comment said overshoot is bounded by "how much can arrive in ≤5s across however many parallel agents share this secret." That overstates it, and I'd rather say so than ship a fix premised on a wrong number.

collect_batch awaits rx.recv() with a 5-second timeout — it returns the instant one event arrives, then fill drains the rest with non-blocking try_recv. So the 5s interval only applies when the channel is idle, i.e. when there's no spend to flush anyway. Under load the counter lagged by one loop turn, not five seconds.

The race was real, just millisecond-scale rather than seconds-scale.

What changed

CacheStore::incr_by(key, delta, ttl) -> Option<i64> — a signed add returning the new total, distinct from the existing incr (+1, u64, for rate limiting). The in-memory implementation does the read-modify-write under DashMap's entry lock, so concurrent charges accumulate. A get_raw/set_raw pair keeps only the last write — which is precisely how spend slipped past a cap.

Charges apply to the counter before the database round-trip, since the counter is what pre_forward reads to decide on the 402.

record_spend reconciles instead of overwriting. This is the subtle one:

if cached.is_none_or(|c| c < total) { cache.set_raw(&counter, &total.to_string(), ...) }

The durable row is a floor — raise the counter to it when the cache is behind (cold start, eviction, a lost increment), never lower it. The old blind set_raw(total) would have rolled back charges already applied for the next batch and let that spend through a second time. Keeping the overwrite alongside charge-time increments would have been worse than either alone.

Deliberately not Redis

The cache is a single-instance in-process DashMap and is already atomic per key, so a single gateway gains nothing here from Redis. What Redis buys is durability across restarts — which the PostgreSQL floor already covers on rehydrate — and shared state across replicas, which isn't the deployment shape. Adopting it stays an option; it is not a prerequisite for this fix, and the incr_by primitive works identically behind a Redis backend later.

Fail-open is unchanged throughout: a cache miss or error still admits the request.

Tests

3 new, the important one being 64 concurrent tokio::spawned charges that must sum to exactly 64,000 — it fails against a get_raw/set_raw implementation. Plus the durable-floor interleaving, and an unparseable value being treated as 0 rather than poisoning spend accounting.

cargo test -p onecli-gateway              # 618 passed, 0 failed
cargo clippy --all-targets -- -D warnings # clean
cargo fmt -- --check                      # clean

Still open from #8's review

The other two comments — the hand-maintained pricing table silently metering unknown models as free, and the cross-language constant duplication between budget.rs and budget-service.ts — are not addressed here. They're independent and I'd rather they land as their own change than pad this one.