WT-18405 makes a disaggregated follower refuse to drop a table holding data that no installed checkpoint covers, retrying until one arrives. Nothing on the server side tests this. WiredTiger's own tests cover the storage API contract, but not that the ident reaper's retry and the checkpoint installer actually cooperate to complete the drop.

step_up_create_drop_since_installed_checkpoint.js now drops an empty table, so it only exercises the case where the refusal never triggers.

Suggested shape: with checkpoint installs pinned on the secondary, write to a table, let the leader checkpoint, then drive replication past that checkpoint before dropping. The secondary's drop is refused; releasing the pin lets the checkpoint install and the drop complete.

The ordering is the whole trick. The secondary must have applied past the covering checkpoint before it applies the drop. Otherwise the applied optime stays frozen below it, the checkpoint can never be selected for install, and the test hangs rather than fails — see SERVER-134216.