WT-18179 refuses to open a live stable table on a follower. Two shared tables are exempt from that rule. The shared metadata table is opened live and then marked outdated on a follower, by design. The shared history store is opened live and stays live. This ticket covers closing that exemption.

Where a follower opens the live shared history store today:
1. Connection open: recovery and startup create and configure it.
2. Every reconfigure: __wt_hs_config runs in the tail of every reconfigure, including every checkpoint pickup and the step-down itself, and re-opens a live handle to set file_max. A pickup marks the old handle outdated and the same reconfigure immediately creates a new one.
3. The eviction server pre-caches history store cursors; its role read can race a step-down and open one more live handle.
4. Resolving a prepared operation on a tree frozen by a step-down opens it (txn.c prepared resolution).
5. Debug dump paths.

Why this should be done:
A follower reads checkpoints, and every data checkpoint pins its matching history store checkpoint, so the pair can never disagree. A live history store handle has no pairing. The one reader population that uses it is a reader still sitting on a live tree that a step-down froze.

The failure scenario:
A reader with read timestamp X holds a cursor across a step-down. Until the first checkpoint pickup the live history store still holds the old leader's content and every read is correct. After the first pickup the live history store follows the new leader, whose cleanup can remove versions below its own oldest timestamp. The frozen reader's next history read then finds nothing and reports a committed value as missing, with no error. Two reads in one transaction can also disagree.

Why this is not urgent:
1. The window needs a reader that crosses a step-down, stays alive past the first checkpoint pickup, and then needs an old version from history. Layered cursors reroute to checkpoint views on their next operation outside a transaction, so only long-running transactions and direct file cursors remain exposed.
2. WT-18179 closed the feeder paths: a follower can no longer create unmarked live data handles, so the exposed population cannot grow.
3. WT-17968 (hold the leader's oldest timestamp back for follower readers) would remove the danger for timestamped readers when it lands.

Suggested work items:
1. Skip or outdate the shared history store in __wt_hs_config and at startup on a follower. The local history store must stay live, ingest eviction writes to it. Step-up must configure the shared history store as the new leader.
2. Fix the eviction pre-cache race.
3. Decide the frozen reader's behavior at the history store lookup: refuse with a rollback, or give it a pinned pair.
4. Document the shared metadata open-then-outdate pattern as the model, or align the history store with it.