During checkpoint log recording, __wt_checkpoint_log (txn_log.c line 452) handles the WT_TXN_LOG_CKPT_START case by copying the active transaction snapshot into a scratch buffer (txn->ckpt_snapshot) allocated via __wt_scr_alloc. The encoding loop (line 529) calls 
__wt_vpack_uint for each snapshot entry, advancing the pointer p past the written bytes. However, txn->ckpt_snapshot->size is never updated after the loop; it remains 0 as 
initialized by __wt_scr_alloc. In the WT_TXN_LOG_CKPT_STOP (line 534), ckpt_snapshot 
is passed to __wt_struct_size and __wt_struct_pack via format "IIIIu". The 'u' specifier 
determines the byte count to copy from item.size (packing_inline.h, case 'u', line 419), 
so with size == 0 the entire snapshot payload is silently omitted from the on-disk 
checkpoint log record even when ckpt_nsnapshot > 0.

For Reproduce;
A catch2 unit test (test_ckpt_snapshot_size.cpp) reproduces the bug and verifies the fix. (I added before/after outputs on JIRA).
In a scenario where one snapshot entry is injected into snapshot_data before WT_TXN_LOG_CKPT_START is called, __wt_vsize_uint(42) == 1 byte is expected in ckpt_snapshot->size after START returns.
Without the fix, size remains 0, causing REQUIRE(txn->ckpt_snapshot->size == expected_size) to fail with expansion 0 == 1.
With the fix, the size is correctly set and the encoded ID round-trips through __wt_vunpack_uint back to the original value.