We should ensure that the table_id of a dropped table would not be reused for any new tables in the future. (And for the purposes of this ticket, we do not need to consider abandoned checkpoints.) Currently, the next available table_id depends on the largest table ID in the metadata table.

The following process would now result in table ID reuse:

1. Create a table
2. Drop a table
3. Create a checkpoint (as we are not dealing with abandoned checkpoints in this ticket)
4. Reopen the connection without local files
5. Create a table

We should solve this by preserving the largest allocated table_id in checkpoint metadata, i.e., page 1 of table 1, which is constructed and written in __wt_disagg_put_checkpoint_meta. We should add either the largest allocated table ID or the next available table ID to the second line of the checkpoint metadata page (it should not start a new line to make parsing simple), e.g.:

    WT_ERR(__wt_buf_fmt(session, buf,
      "%s\n"
      "timestamp=%" PRIx64 ",next_table_id=%" PRIu64,
      checkpoint_root_copy, checkpoint_timestamp, next_table_id));

Picking up a checkpoint should update the next available table ID in WiredTiger, unless the current next available table ID is greater.

If there is no table ID information in the checkpoint metadata, that should not be an error, so that we can safely upgrade our current canary clusters.