Context

In the disaggregated storage code path, "turtle" is the established term for the bootstrap object on the page log — the on-page-server analog of the local WiredTiger.turtle file. It lives at the special table id WT_SPECIAL_PALI_TURTLE_FILE_ID (id 0 in the special namespace at src/include/btree.h:131, comment: "shared turtle data") and stores the WT_DISAGG_CHECKPOINT_META blob (metadata_lsn, metadata_checksum, database_size, version, compatible_version) with version macros WT_DISAGG_CHECKPOINT_TURTLE_VERSION* at src/include/connection.h:170-172. WT itself reads it during connection bootstrap via pl_open_handle(WT_SPECIAL_PALI_TURTLE_FILE_ID) + plh_get at src/conn/conn_layered.c:1496-1497.

Motivation

The turtle pins the LSN, checksum, and version of every other page WT will then fetch. A dedicated command hides the magic table id and owns the latest-LSN auto-discovery.

Suggested solution

• Default behavior: open the turtle handle (pl_open_handle(0)), call pl_get_complete_checkpoint_ext to discover the latest turtle LSN if --lsn is omitted, then
    plh_get page id 1 (the canonical turtle page) at that LSN. Output the bytes the same way get-page would (hex by default, -j JSON, -x raw).
    - With --lsn=N: skip the discovery and read directly at that LSN. Useful for forensic "what did the turtle look like 3 checkpoints ago?".

Output

lsn=7633951893558919182
metadata_lsn=7633951893558919180
metadata_checksum=0x1d8d4a08
database_size=...
version=2
compatible_version=1