Client-side error accounting depends on onError

Clients report some statistics about the frequency that they observe different errors (e.g. `transaction_too_old`, `future_version`, `not_committed`, etc.). These errors are counted when they are passed to the `onError` function.

There are many use-cases where clients either don't retry a transaction or write their own retry loops and don't use `onError`. In these cases, this reporting does not work.

If possible, we should try to count errors differently so that we get accurate results regardless of whether the transactions get retried with the internal mechanism.

Start by tracing where client error statistics are recorded and how errors reach the onError callback. Determine an accounting point that also covers transactions using custom retry loops or no retry, then verify that reported frequencies remain accurate in both internal and external retry paths.

Written by the indexing model from the issue text.