__drop_layered() drops the stable constituent before the ingest one, and __drop_file() truncates the history store for the dropped btree immediately, outside metadata tracking. A failure after that point unrolls the metadata but not the truncation.

Since WT-18405 the ingest drop returns EBUSY when no checkpoint covers the ingest content, so a refused drop now routinely leaves the table in place without its history: current reads and reads of ingest content succeed, reads at an older timestamp return nothing.

Reproducer on a leader: publish and checkpoint the table, write at 10 and checkpoint, write at 20 and checkpoint, set step_down_timestamp=30, write at 40, drop. The drop is refused and a read at timestamp 10 then returns no rows.

This fails test_layered_async_stepdown10 in unit-test-extra-long on every variant since e9cf6905.

Fix: defer the history store truncation to metadata tracking commit, as __wt_meta_track_drop() already does for the file removal.

Known limitation

A crash between the metadata commit and the deferred truncate leaves history store records for a dropped btree ID, which only matters if that ID is reused: __recovery_file_scan() recomputes next_file_id from the metadata, so dropping the highest-ID file frees it across a restart and re-introduces WT-13703. Accepted, since the truncate was already best effort; closing it needs WT-18386's persist-and-retry pattern, whose "table IDs are not reused" premise does not hold for local file IDs.