Motivation:

log->alloc_lsn is advanced from two runtime code paths: _log_slot_close (src/log/log_slot.c) during slot consolidation, and log_newfile (src/log/log.c) on a log-file switch. A long-standing XXX comment in _log_slot_close notes the desire for a single piece of code to advance the LSN.

Multiple writers of the same shared LSN under differing synchronization is the design smell that made the recent logging TSan data races (WT-12734, WT-16301, WT-15708) subtle to reason about. Centralizing the advancement into one code path shrinks that race surface and makes the invariant easier to maintain.

This is a code-quality refactor, not a bug: the current code is correct under the log slot lock.

Current writers of log->alloc_lsn:

• __log_slot_close - src/log/log_slot.c (steady-state advance to slot_end_lsn)
• __log_newfile - src/log/log.c (advance to the start of a new log file on file switch)
• one-time initialization (WT_INIT_LSN in __wt_logmgr_create) - out of scope

Tasks:

• Refactor so a single helper/code path advances log->alloc_lsn at runtime.
• Remove the legacy XXX comment (a FIXME referencing this ticket is being added in the meantime so the marker is tracked).

Definition of Done:

• log->alloc_lsn is advanced from a single runtime code path (excluding one-time initialization).
• The XXX/FIXME marker in __log_slot_close is resolved.
• No functional or behavioral change; existing log and TSan tests remain green.