A disaggregated tree can address another table's page log while its metadata records its own table. WT-18509 hit this: a block handle cached by file name outlived a drop and a recreated table adopted it. WT-18509 fixes that binding, but nothing detects the resulting state.

Existing checks cannot see it. _verify_unique_btree_ids() and checkpoint pickup validation (WT-14730, WT-18150) compare metadata against metadata, and both sides agree here. The page header carries no owning table ID, so a page read from the wrong table looks valid. The only signal was the checkpoint size check in _verify_one_checkpoint(), which a coincidental match defeats, which is fatal only under HAVE_DIAGNOSTIC (FIXME-WT-18038), and whose fix_btree_size mode overwrites the size instead of reporting it.

Add two checks:

1. In __wti_block_disagg_open(), assert the returned handle's tableid equals the opening tree's ID. Always on, fires at the bad binding, and guards the WT-18509 lookup against regression.
2. Have verify read through a page log handle opened on the table ID in the metadata, so every page cookie must resolve under the table the metadata claims. This is independent of how the divergence arose, so it also covers a checkpoint address written from a stale queue entry.

Verify does not run against stable tables in the workload that found WT-18509, so check 2 alone would not have caught it. Whether stable constituents should be verified routinely is a separate question.