Event IDs with "block" 0 happens on the first 2 blocks

Nobody has claimed this yet.

The way we setup `latest_tid` in ledger and kvstore makes it so that we repeat the `latest_tid` of the first block;

1. on the first block, `latest_tid` starts at 0.
2. during commit, `latest_tid` is set to `height << SOME_INDEX`. `height` is the current height, which is 0.
3. during the next block, `latest_tid` starts at 0 because of the above, and so any events would have the same IDs as the previous block.
4. during commit, `height` is now `1` and `latest_tid` will be set properly.

We set `latest_tid` to the block height so that we can resume with a known value when resetting the process. This actually highlighted that we cannot resume a non-blockchain ledger.

There are multiple solutions here, but the simplest one would likely be never to set `latest_tid` and only increment it (and save it in the database).

Also, it would be useful to have `height` be not the latest height committed, but the height of the block being built. This would solve some inconsistencies around the storage.

Start by tracing latest_tid initialization and commit handling in the ledger and kvstore, then inspect how block height is recorded during block construction. Done means event IDs remain unique across the first two blocks and the stored height semantics are consistent with the block being built.

Written by the indexing model from the issue text.