Summary

Since WT-18176 (962a690012, "Require the stable disaggregated schema epoch to be set
before publishing"), every schema_disagg_abort csuite task fails immediately with a panic.

Failing tasks

All on wiredtiger-disagg, variants amazon2023-disagg-stress and
amazon2023-disagg-asan-stress:

• schema-disagg-abort-test-disagg-1
• schema-disagg-abort-smoke-test-disagg-1
• schema-disagg-abort-switch-test-disagg-1

Example: task

#3  __wt_abort (session=0x73437fc9bae0) at src/os_common/os_abort.c:32
#4  __wt_panic_func (..., func="__schema_publish_disagg_schema_epoch", line=45,
      fmt="publish requires the stable disaggregated schema epoch to be set")
#5  __schema_publish_disagg_schema_epoch (uri="table:schema_0_6", schema_epoch=1)
      at src/schema/schema_publish.c:45
#6  __wt_schema_publish (...) at src/schema/schema_publish.c:88
#7  __session_publish (...) at src/session/session_api.c:1428

Root cause

The test has a bootstrap cycle. Its timestamp thread is the only place that sets the stable
schema epoch, and it derives the value from min(published_epoch) across the schema
workers, skipping while that minimum is 0 (test/csuite/schema_disagg_abort/workload.c:308).
So the stable epoch stays unset until the first WT_SESSION::publish — which is exactly
the call WT-18176 now turns into a panic. The failure is deterministic, not a flake.

The stable epoch is in-memory only (txn_global->has_stable_disaggregated_schema_epoch is
set solely by WT_CONNECTION::set_timestamp; there is no recovery path), so each connection
open needs it set again — including the step-down reopen in the test's switch mode.

Fix

In workload_run_phase(), reserve one epoch from the shared counter and set it as the
stable disaggregated schema epoch before the phase's workers start. The reserved value sits
above every epoch already published (so set_timestamp never moves the epoch backwards)
and below every epoch the phase is about to publish (so the schema_epoch > stable check
still holds).