Two disaggregated size counters clamp on underflow rather than failing: diagnostic builds assert, production logs and clamps. Both clamps hide a real accounting bug, and both should become WT_ASSERT_ALWAYS once the underlying bug is fixed. This ticket covers flipping both.

Block size (added by WT-18036)

__wti_block_disagg_decrease_size, src/block_disagg/block_disagg_size.c. Clamps to 0 and logs a warning. Becomes:

      WT_ASSERT_ALWAYS(session, orig >= size,
        "disaggregated block size underflow: decrementing %" PRIu64 " from %" PRIu64, size, orig);
  

Blocked on the decrement-exceeds-increment behaviour the function's own comment describes ("Clamping to zero hides a real accounting bug where we decrement more than was added"); context in WT-17000.

Database size (added by WT-18399)

__checkpoint_update_disagg_database_size, src/checkpoint/checkpoint_txn.c. Clamps to WT_DISAGG_CHECKPOINT_SIZE_BUFFER and logs an error, so a wrapped uint64 is never published
as the database size. Becomes:

      WT_ASSERT_ALWAYS(session, db >= sub && db - sub >= WT_DISAGG_CHECKPOINT_SIZE_BUFFER,
        "disaggregated database size underflow: decrementing %" PRIu64 " from %" PRIu64, sub, db);
  

Blocked on WT-18293: the drop accounting can over-subtract a reused URI's checkpoint size, which is what drives the database size below the buffer today.

Both sites carry a FIXME-WT-18039. Flipping either one turns a silently wrong size metric into a production abort, so each should only move once its own blocker is closed. The two are independent and can be done separately.