Symptom

Evergreen runs of -s 4 -T 2 fail with:

test_schema_disagg_abort: FAILED: stable timestamp not set after 60 seconds: Connection timed out
test_schema_disagg_abort: FAILED: Child process abnormally exited: Invalid argument

The checkpoint thread's 60-second startup watchdog fires because no stable timestamp is ever set. This has the same surface signature as WT-18084, but that fix is already merged – this is a new, distinct deadlock in the replacement coordination scheme.

Root cause

The post-WT-18084 scheme publishes a globally monotonic epoch per schema op; the timestamp thread sets the stable timestamp only when all workers have a non-zero stable_ready_ts; a worker's queued inserts release (feeding stable_ready_ts) only when the global minimum published epoch reaches that insert's table-create epoch.

When thread startup is skewed (loaded CI host):

1. Worker 0 exhausts its pool early – creates at epochs 1-4, published_epoch(W0) = 4.
2. Worker 1's creates all land above W0's ceiling – creates at epochs 5-8. Its queue releases only when min(published) >= 5, but the min is pinned at 4. So stable_ready_ts(W1) = 0 forever.
3. Timestamp thread polls workers_min and gets 0, never sets the stable timestamp.
4. W0's drops spin on EBUSY (WT_DIRTY_DATA) because no checkpoint has run yet.
5. No checkpoint runs because it waits for stable_set.

Four-link circular wait. Engine EBUSY on dirty-close is correct behavior; the bug is entirely in the test's bootstrap coordination..