KVDropPendingIdentReaper::immediatelyCompletePendingDropAtTimestamp() retries ObjectIsBusy with no cap and no deadline, on the oplog applier thread. The engine also refuses while a table holds writes no checkpoint covers, which a disaggregated follower - and any node for the duration of a PIT restore - cannot clear. Blocking the applier is what prevents such a checkpoint from becoming installable, so the wait can never succeed.

Observed with WT-18405 applied: the applier spins on internal-indexBuild-*, lastApplied freezes one increment below the drop's timestamp, and PIT restore fasserts 11479316.

Fix: bound the in-place retries, then leave the ident drop-pending and return OK (dropIdent has no acceptable errors in kOpsMap, so a non-OK status fails the batch). Let the background reaper complete a drop already applied from the oplog without a write intent, since finishing it replicates nothing.