__checkpoint_update_disagg_database_size, src/checkpoint/checkpoint_txn.c, increment branch:

if (delta > 0) {
    WT_ASSERT(session, UINT64_MAX - db >= (uint64_t)delta);
    __wt_disagg_set_database_size(session, db + (uint64_t)delta);
}

Diagnostic builds assert. Production builds have no check, so a wrapped uint64 would be published as the database size. The decrement branch immediately below clamps to WT_DISAGG_CHECKPOINT_SIZE_BUFFER and logs an error in production, so the two directions are handled inconsistently today.

Candidate treatments:

• WT_ASSERT_ALWAYS, matching what the surrounding block comment already promises, that a wrapped uint64 is never published:

    WT_ASSERT_ALWAYS(session, UINT64_MAX - db >= add,
      "disaggregated database size overflow: incrementing %" PRIu64 " by %" PRIu64, db, add);

• a clamp plus an error log, matching the decrement branch.

Separate from WT-18039, which covers the two size underflow sites. Unlike those, this site has no blocker: neither the over-subtraction described in WT-18293 nor the decrement-exceeds-increment behaviour in WT-17000 can drive the database size past UINT64_MAX, which needs roughly 16 EiB of accounted storage. It can be picked up at any time, independent of both.

The site carries a FIXME referencing this ticket.