Related to the WT_CELL_ADDR_DEL verifier fix: when reconciliation merges a fast-truncated child's address cell into an internal page's aggregate, it currently merges the child's raw (pre-truncate) time aggregate as-is. That raw aggregate's stop fields (e.g. newest_stop_ts = WT_TS_MAX) are stale — they describe the child's content before the fast truncate, not after — while the page_del structure on the same cell carries the actual, current stop point for the whole subtree.

Change reconciliation (src/reconcile/rec_row.c, src/reconcile/rec_col.c) to compute an effective child aggregate before merging into the parent:

• keep the raw child aggregate's start fields (oldest_start_ts/txn, newest_start_durable_ts)
• replace the stop fields with the ones derived from page_del (stop timestamp, durable timestamp, txn id)

Add a helper (e.g. in src/include/timestamp_inline.h) to apply page_del stop information onto an aggregate, and reuse it from both reconciliation and the verifier (prerequisite 1) so the two stay consistent.

This corrects existing fast-truncate aggregate semantics: a parent internal page's aggregate should reflect that its subtree is deleted as of the truncation's stop point, not be artificially widened by a stale pre-truncate child aggregate. It also updates src/docs/arch-fast-truncate.dox to describe the corrected semantics.

Depends on the verifier fix (prerequisite 1) landing first, so that checkpoints written with the corrected, tighter parent aggregate are not rejected by verification logic that still compares against the stale raw child aggregate.

This is prerequisite 2 of a 3-ticket rollout (verifier fix → reconciliation aggregate fix → internal-page skip optimization, the last being WT-18406).