Up to this point in the PR stack, all the changes have been to the producer side, including new row types that encode the necessary information to decode a Ledger total on the client. This PR updates the client to compute the totals.

Ledger totals are rendered into the output as thenables. The client traverses the Unit graph to determine which Ledger entry rows should contribute to a particular total, based on where its captureLedgers call is located in the graph. It must also account for when data is reused across different parts of the Unit graph (i.e. due to React.cache, or object deduping). When this happens, the server emits a "reference" row (F), which allows the client to accumulate the Ledger entries in the reused part of the graph.

As it traverses all the Ledger entries, it accumulates them into a total that is used to resolve the thenable. This happens only once the stream has closed and there's no more data left to receive, guaranteeing the frozen totals remain accurate.

There's currently no ability to read the total of a still-open stream, though in the future we could choose to resolve the totals earlier in cases where we can prove they will never change, due to the monotonic nature of Ledgers. For example, a Bit ledger can be closed upon the first write, because a Bit that is set can never be unset by a later entry.