Reopening an idle table requires disk I/O while holding the global schema lock exclusively, which blocks all other threads trying to open cursors. This change converts the schema lock into a read/write lock and takes it in shared mode during the open and reopen paths. Threads can now reopen different tables in parallel without waiting on a single I/O operation.

The dhandle sweep closes idle tables. The next access reopens the table and performs disk I/O (block-manager open, reading the checkpoint and root page) under an exclusive global schema lock. On a connection with ~200K tables and a rotating working set, reopens happen often. Even when table creation is near zero, every thread that needs the schema lock to open a cursor waits behind that single I/O.

Proposed fix: make the schema lock a read/write lock. The open and reopen path takes the lock in shared mode, allowing reopens of different tables to run in parallel. Operations that change connection-level schema state still take the lock exclusively: create, drop, verify, alter, rename, truncate, salvage, compact, backup, rollback to stable, recovery, checkpoint prepare, and disaggregated-storage publish. The per-dhandle WT_DHANDLE_EXCLUSIVE flag is independent of the schema lock and continues to serialize same-uri races, making the shared path safe. The disaggregated open path keeps the exclusive lock.