When a REMOVE is processed at checkpoint, __disagg_accumulate_drop_size decides what to subtract from database_size using (a) whether the URI is in local metadata now and (b) the checkpoint entry in the queue entry's metadata snapshot. Neither identifies the incarnation the REMOVE belongs to, so create/drop/create reuse of one URI corrupts the accounting in both directions.

Deterministic leak (attached test_disagg_checkpoint_size23.py, single-threaded, one cycle): create + data + checkpoint; drop; recreate the URI before the next checkpoint; drop again. Nothing is left in the database and every REMOVE was processed, but the data's size never leaves database_size:

empty=1050207, with_data=1563863, after_all_dropped=1563571

The URI is present at processing time, so the REMOVE is treated as a rolled-back drop (conn_layered.c:649) and skipped.

Over-subtraction (measured in test/csuite/schema_disagg_abort under create/drop churn): one checkpoint subtracted 41,241 bytes — 233 x the same 177-byte checkpoint entry of one reused URI — breaching WT_ASSERT(database_size >= WT_DISAGG_CHECKPOINT_SIZE_BUFFER) (checkpoint_txn.c:1030). The floor is easy to breach because database_size is seeded to exactly the buffer (checkpoint_txn.c:977), so the margin is only the accounted user data. Repro: test_schema_disagg_abort -r l -t 10 -T 2 -u 4, ~30% of runs.

Likely the size-accounting symptom of the stale-metadata-under-URI-reuse family (WT-18068, WT-18230). debug.database_size_fix already exists to repair the drift wholesale. Reproduced at develop merge-base 6bb7d02485; src/ unmodified.