feat(gateway)!: reserve capped API key spending before execution

[drewstone]

Finite API-key caps previously checked settled charges while concurrent requests could execute beyond the remaining budget. The gateway now reserves the full quoted customer charge before compute, reconciles matching usage once, and releases only pre-execution holds. Outstanding executions retain their reservations across workers and rate-counter pruning.

Capped execution requires a prepared stream that enforces the supplied provider, token, and tool limits. Missing or malformed preparation fails closed without falling back to unbounded execution. Current remote agent-app adapters do not implement this enforcement contract and remain unsupported for capped keys; explicitly uncapped keys retain their existing behavior.

Adoption requires the additive reservation table from sqlApiKeyStoreSchemaStatements and apiKeyReservationLifecycle wiring. Version 0.10.0 reflects this capped-host contract change.

Validation: 480 tests passed, typecheck and build passed on Node 24.18.0. Tests cover competing SQL stores, migration preservation, cap/expiry/revocation changes, duplicate execution, settlement replay, uncertain abort retention, malformed preparation, and abort listener cleanup. Independent SQL and prepared-stream reviews found no remaining blockers. Concurrency tests use two store instances against one real SQLite database; distributed D1 and real upstream provider enforcement are not claimed.

[tangletools]

Reviewed the prepared execution boundary and verified fixes for malformed preparation falling back to unbounded execution and abort listener cleanup. Independent SQL review covered reservation admission, begin CAS, settlement replay, expiry, and retained uncertain execution. No remaining blockers in this scope. Real distributed D1 and upstream provider enforcement remain explicitly unproven; remote adapters must reject capped execution until they implement enforcement.