When a checkpoint applies a queued REMOVE for a dropped layered table, it subtracts the table's last checkpoint size from the database size. The size currently comes from a snapshot of the stable table's configuration that the drop captures into the queue entry before removing the local metadata (WT-18148 moved this capture to an explicit early step in the drop, since the enqueue now happens after the local rows are gone).

The snapshot is redundant. The shared metadata table already holds the stable table's last checkpointed configuration, refreshed by the block manager's checkpoint callback, and queue processing deletes that row anyway when it applies the REMOVE. Reading the size from the shared row just before deleting it removes the need to carry the snapshot:

• Delete the early metadata search and the stable_value parameter that WT-18148 added to the enqueue function.
• Stop using the queue entry's captured stable value for REMOVE entries entirely (the shared-metadata removal itself deletes by key and does not read the values).
• In the queue processing path, read the shared file: row for the stable table, parse the checkpoint size, add it to the drop size, then delete the row.

This also makes the accounting read the current source of truth at the moment of deletion, rather than trusting a snapshot captured in a possibly earlier leader era. Verify the behavior for an epoch-deferred REMOVE applied after a step-up, and for a table that was created and dropped without ever being checkpointed (no shared row, nothing to subtract).