WT-18405 makes a table drop on a disaggregated follower fail with EBUSY when the table holds ingest writes that no installed checkpoint covers. That change is required, so the server has to satisfy the invariant before it can land again.

The server already enforces this invariant — but only on the node that initiates a drop, where drop eligibility is clamped to the checkpoint timestamp. A replicated dropIdent applied on a follower has no equivalent gate: it checks only that the drop timestamp has passed, never that a covering checkpoint has been installed. A follower whose installed checkpoint lags the drop therefore attempts it anyway and is refused permanently. Taking a local checkpoint does not help — on a follower the bound advances only when a checkpoint is picked up from the leader.

Proposed: gate the replicated drop the same way as the initiator — defer it until this node's installed checkpoint covers the drop timestamp. Together with SERVER-134216 (stop blocking the oplog applier while busy), the drop then completes on a later pass once the covering checkpoint arrives.

Evidence: two Evergreen patches off the same base commit, differing only by WT-18405. step_up_create_drop_since_installed_checkpoint.js fails on both disagg variants with the change and passes on both without it, spinning through 2205 consecutive ObjectIsBusy retries.

Two follow-ups:

• That test deliberately constructs the state which becomes illegal, by pinning the secondary's checkpoint installs with a failpoint. It needs reworking to match the new contract.
• SERVER-122277 proposes the opposite coupling — skip installing checkpoints while drops are pending. WT-18405 needs pickups to proceed in order to clear drops, so check the interaction.