Issue Summary

The model records whether connection logging is on in kv_database_config.logging, populated only from the config("database", ...) workload operation. WiredTiger's actual setting comes from a different place: k_config_base, then the database configuration, then the workload's own wt_config("connection", ...), then the caller's override, appended in that order. Nothing makes the two agree, so the model can believe something false about the connection it is comparing itself against.

They already disagree in tree. ENV_CONFIG in test/model/test/model_workload/main.cpp passes log=(enabled,file_max=10M,remove=false) to five of the six verify_workload call sites, so those runs have logging on while the model records logging=false.

Context

• Follow-up to WT-15069, which introduced the first consumer of kv_database_config.logging: a checkpoint crash taken after the checkpoint transaction commits keeps its checkpoint when logging is on, and loses it otherwise.
• WT-15069 guards only that one operation. kv_workload_runner_wt::do_operation(checkpoint_crash_trigger) compares the connection's WT_LOG_ENABLED flag against the database configuration and throws on a mismatch. That catches a phase-named crash added to a test using ENV_CONFIG, and a fuzzer run with -C "log=(enabled=true)".
• It does not catch the case worth worrying about. Logging changes semantics the model does not model yet — src/btree/bt_handle.c:559 notes that logged objects imply commit-level durability and ignore timestamps. If a second consumer of kv_database_config.logging is added for that, every test in model_workload/main.cpp is modelled wrong, with no phase-named crash anywhere to make the existing guard fire. The failure would be silent and would look like a bug in the new modelling rather than in a long-standing configuration mismatch.
• Only model_workload routes configuration through kv_workload_runner_wt. model_basic, model_checkpoint, model_rts and model_transaction open WiredTiger directly and are unaffected.

Proposed Solution

• Replace the per-operation check with one in kv_workload_runner_wt::wiredtiger_open_nolock, run on every open after wiredtiger_open succeeds:

if (FLD_ISSET(((WT_CONNECTION_IMPL *)_connection)->log_mgr.flags, WT_LOG_ENABLED) !=
  database_config.logging)
    throw model_exception("Connection logging does not match the database configuration");

log_mgr is on WT_CONNECTION_IMPL (src/include/connection.h:1222), so no session is needed. This covers every workload rather than only those containing a phase-named crash.

• Add config("database", "logging=true") to the five workloads at lines 123, 171, 206, 246 and 287 of model_workload/main.cpp. Each is followed by verify_using_debug_log, which reads the debug log and so genuinely needs logging during the run; declaring it makes the recorded state honest rather than turning logging off. The addition is inert for the model today, since logging feeds only the phase-named crash paths.

Two approaches were considered and rejected:

• Forcing the database configuration to win by appending log=(enabled=...) after the overrides. This works mechanically — __config_getraw (src/config/config.c:625) descends into each log=(...) occurrence separately, so duplicates merge per sub-key with last-wins and file_max and remove survive — but it silently overrides a wt_config("connection", "log=(enabled=...)") that a workload author wrote deliberately. Throwing is preferable to ignoring.
• Rejecting the textual presence of log= in the connection configuration and override. Attempted during WT-15069 and backed out: it fails on ENV_CONFIG's bare log=(enabled,...) form and rejects log settings that say nothing about enabled. Comparing the resolved flag avoids parsing entirely.

Definition of Done

• The check runs at connection open rather than per operation, and the per-operation check added by WT-15069 is removed as redundant.
• The five affected workloads declare their logging state, and no workload run leaves the model's belief and the connection disagreeing.
• test_model_workload passes, and model_test passes over a run with conn_logging=1.0 and with conn_logging=0.
• A test that deliberately sets a contradictory connection configuration fails with the new exception rather than producing a wrong verify result.