Outcome: Keep checkpoint pickup fast as the number of tables grows, both during startup and steady-state follower operation. The long-term goal is constant-complexity checkpoint pickup with respect to total table count, so large metadata does not cause pickup to delay reads and writes. WT-19023 advances this goal by creating local ingest constituents on first access rather than during checkpoint installation.

Extend the lazy ingest creation introduced by WT-17915 to steady-state checkpoint pickup. Newly adopted layered tables should create their local ingest constituent on first access, not during checkpoint installation.

Completion criteria: Later pickups do not create or open missing ingest constituents for untouched tables. First access creates one correctly configured local constituent, including under concurrent opens. Existing constituents keep their identity. Drop before first access, restart, recovery, prepared discovery and synchronous role transitions remain correct.

Validation: Test initial and later pickups, repeated installation, concurrent first opens and drop before first access. Compare checkpoint-pickup time, schema-lock time and first-access latency against the WT-17915 baseline. Record the benefit and the cost deferred to first access.

Reason for a follow-up: The intent is to move incrementally. The release-priority goal is improving startup performance. Let WT-17915 land first, give it time to stabilize, and then extend the policy using the existing lazy-open mechanism. Keeping this follow-up separate lets us test, isolate and revert any issues without rolling back the startup improvement.

Source ticket: https://jira.mongodb.org/browse/WT-17915

Review discussion: https://github.com/wiredtiger/wiredtiger/pull/15042#discussion_r4450955294