This is a follow-up to WT-15589.

WT-15589 was intended to introduce a stricter check ensuring that an LSN is not ahead of the materialization frontier but several issues couldn't be resolved at that time:

1. Frontier initialization during step-up:
When stepping up, the code needs to perform reads before knowing the current frontier position. This requires temporarily ignoring the condition until a valid value is available with 0 used as an "uninitialized" indicator. This logic needs verification. Ideally, we should not perform any reads before knowing the current frontier LSN.

2. Magic LSNs from the Server:
The Server sets a magic (non-zero) value as the LSN which makes WiredTiger treat it as valid causing the check to fail. As of this ticket's creation, it's unclear whether we plan to continue using these magic LSNs or eliminate them.
Contacts: kaitlin.mahar@mongodb.com, keith.smith@mongodb.com, chenhao.qu@mongodb.com

3. Frontier LSN updates on secondaries:
It's not clear whether the frontier LSN is being properly updated on secondary nodes. This logic should be reviewed and confirmed.

4. Intentional crash upon reads ahead of the materialization frontier:
Reading ahead of the materialization frontier introduces a latency penalty but isn't a fatal condition. We don't want to crash a production node in this case. However, we do want to catch such events during testing - ideally crashing the application to capture a call stack and core dump for investigation.
A reliable way is needed to identify when we're running in a test environment, or alternatively, to introduce a mechanism that allows safely toggling the behavior between "crash on error" (for testing) and "report and continue" (for production). It could be done via checking for diagnostic build or something else.
Contacts: chenhao.qu@mongodb.com, keith.smith@mongodb.com