WT-18179 makes the btree open return EBUSY for every open of a live stable table on a follower, for every caller. Two hardening follow-ups were deferred.

1. Assert the invariant.
After WT-18179, the only live stable handles a follower may hold are the ones a step-down froze, and those are readonly and outdated. Add a diagnostic check that a follower never holds a writable live stable handle. For example, the sweep or a handle-list walk can assert that every open live stable handle on a follower is readonly. Today the invariant is only enforced at the action level (the page-modify asserts); a structural check catches a leaked handle before anything writes through it.

2. Narrow the refusal to the step-down race.
The open refusal treats two populations the same:
- Opens that raced a role change: dispatched on a leader-role read, completed on a follower. Expected, retried, and converted to a rollback by the layered cursor.
- Opens that begin on a follower with no role change involved: a direct file cursor on a constituent, the wt tool, the statistics log with file sources.
Distinguish them, for example with a dispatched-as-leader marker or a role generation carried by the opener. The raced open keeps EBUSY. The follower-origin open can then be asserted in diagnostic builds, or refused with a clearer error.

Blocker to resolve first:
Some follower-origin opens are legal today (diagnostics, the statistics log, the wt tool). Either declare them unsupported or exempt them before adding the assert, otherwise diagnostic builds abort on legal API use.

Why this is not urgent:
WT-18179 already refuses both populations loudly. The split adds diagnosis and earlier detection, not safety.