Preserve SQLite aggregate counters when fingerprint series admission fails

Feifan Zhou found this while operating RivetKit 2.3.15 with native SQLite profiling enabled.

Problem

Fingerprint admission and the other fallback use the same shared Prometheus series budget. If the budget can reserve the base tuple but cannot reserve a statement or transaction tuple, RivetKit increments rivetkit_sqlite_fingerprint_overflow_total{reason="series_budget"}, retries with other, and then drops the full profile when that reservation also fails. The operation/outcome counters are part of the fingerprint tuple, so exact aggregate counts are unavailable precisely when fingerprint attribution is exhausted.

A minimal example is a process with a 1,000-series budget. One actor/transport base tuple reserves 891 series. A statement tuple requires 147 more series, so neither the selected fingerprint nor its other fallback can be admitted. Overflow reports the attribution loss, but aggregate operation/outcome counts are also lost.

Request

Please either:

• pre-reserve other aggregation tuples for the expected operation type, fingerprint source, transaction mode, and storage transport combinations; or
• provide fingerprint-free aggregate operation/outcome counters that do not depend on fingerprint tuple admission.

Acceptance criteria

• Exact aggregate operation/outcome counts remain available when fingerprint admission fails.
• fingerprint_overflow_total continues to report attribution loss.
• Tests cover the case where the selected fingerprint reservation and the current fallback reservation both fail.

Trace SQLite profiling's fingerprint admission, shared Prometheus series-budget reservation, and the other fallback first. Add coverage for both reservations failing, then verify exact aggregate operation/outcome counts remain available while fingerprint_overflow_total still reports attribution loss.