Fix fragment corruption in the GlobalOrderWriter

[davisp]

Previously there was an issue with the GlobalOrderWriter when using a
maximum fragment size. If we resumed a write where the first tile would
cause the partially written fragment to overflow the set maximum size,
we failed to check that a single tile could fit. This resulted in a
convoluted path where dim_tiles[-1].cell_num() return a reasonable
result (instead of segfaulting or throwing an exception).

This lead us to writing the wrong last_tile_cell_num value in the
FragmentMetadata. When reading the last tile from one of these corrupted
fragments, the logic in Tile::load_chunk_data would throw an exception
when the expected size was calculated off an invalid
last_tile_cell_num which caused an exception to be thrown and rendered
the last tile of the fragment unreadable.

The fix is simply to make sure we check if a single tile can fit and if
not, to create a new fragment. For a belt and suspenders approach to
safety, we've also changed the code in WriterBase::set_coords_metadata
to use std::vector::at instead of std::vector::operator[] so that
bounds checking is performed and assertion is thrown rather than writing
a bad FragmentMetadata to disk.

---

TYPE: BUG
DESC: Fix fragment corruption in the GlobalOrderWriter

[shortcut-integration]

This pull request has been linked to Shortcut Story #34072: Query produces no results. Suspected MariaDB crash.

[davisp]

When we merge this, make sure to use the rebase instead of squash so that the two commits are kept in the history as there are two subtle halves to this bug that should be called out separately.