Background

Raised while fixing WT-18991. `__wt_txn_global_set_timestamp` only enforces oldest <= stable when both timestamps exist, so an application can call set_timestamp with oldest_timestamp while no stable timestamp has ever been set.

Why it matters

The stable timestamp is the only stable point WiredTiger keeps. Without one:

• A checkpoint records no checkpoint timestamp: `__checkpoint_prepare` assigns `txn_global->checkpoint_timestamp` from the stable timestamp only when a stable timestamp is set, so the checkpoint carries `WT_TS_NONE`. A checkpoint without a stable timestamp is accepted unless `precise_checkpoint=true`, which defaults to false.
• A disagg checkpoint's recorded oldest is `min(oldest, checkpoint timestamp)` in `__wt_meta_sysinfo_set`, so it collapses to zero as well.
• Verification of a disaggregated follower then has no valid bound: for a leaf rebuilt from a base image and a delta whose parent aggregate is empty, `__time_value_validate_parent_stable` compares cell timestamps against the checkpoint timestamp and rejects valid data (WT-18991).
• Any consumer that treats an empty aggregate as "everything is stable" loses that guarantee, because no stable point exists to check against.

Current state

• 37 of the 995 Python suite tests set oldest_timestamp and never set stable_timestamp.
• In MongoDB, oldest and stable are advanced by different paths (oldest from the timestamp monitor and checkpoint install, stable from the replication layer), so their ordering at startup and during role changes needs checking before adding a restriction.
• Etienne's concern on WT-18991 review: this is a design decision with broad impact; it likely happens in several areas.

Questions to answer

1. Is a stable timestamp meant to be required for any timestamped workload, or is a database with timestamps but no stable point a supported configuration?
2. If it is not supported, can the rule be enforced at set_timestamp time, and what is the failure mode for existing users (an error on the oldest call, on the first checkpoint, or a warning)?
3. If it is supported, what should verify and the aggregate consumers treat as the bound when no stable point exists?
4. What does MongoDB actually do: can oldest be set before stable on startup, on a standby installing a checkpoint, or during step-up?
5. How many in-tree tests would need to change, and does the change break any upgrade or restore path (recovery sets oldest from local metadata)?

Definition of done

A recommendation with evidence for one of: enforce oldest-after-stable, define the no-stable semantics for verify and the aggregate consumers, or keep the status quo with the constraints documented. Related: WT-18809 (pass the stable bound in from the caller).