reftable: write correct max_update_index to header

In 297c09ea (refs: allow multiple reflog entries for the same refname, 2024-12-16), the reftable backend learned to handle multiple reflog entries within the same transaction. This was done modifying the update_index for reflogs with multiple indices. During writing the logs, the max_update_index of the writer was modified to ensure the limits were raised to the modified update_indexs.

However, since ref entries are written before the modification to the max_update_index, if there are multiple blocks to be written, the reftable backend writes the header with the old max_update_index. When all logs are finally written, the footer will be written with the new min_update_index. This causes a mismatch between the header and the footer and causes the reftable file to be corrupted. The existing tests only spawn a single block and since headers are lazily written with the first block, the tests didn't capture this bug.

To fix the issue, the appropriate max_update_index limit must be set even before the first block is written. Add a max_index field to the transaction which holds the max_index within all its updates, then propagate this value to the reftable backend, wherein this is used to the set the max_update_index correctly.

Add a test which creates a few thousand reference updates with multiple reflog entries, which should trigger the bug.