After WT-16465, we have a new trim command as such:

    /*!
     * Discard an table into the paging/logging service.
     *
     * @errors
     *
     * @param plh the WT_PAGE_LOG_HANDLE
     * @param session the current WiredTiger session
     * @param table_id the table to be discarded
     * @param start_lsn the LSN at which table was created.
     */
    int (*pl_trim_table)(WT_PAGE_LOG *page_log, WT_SESSION *session, uint64_t table_id,
        uint64_t start_lsn);

Why?
The start_lsn is useful for the page server because it sets the bounds on which page servers may have data for the table. E.g. consider a log with 1,000 PSEs, each with 3 page servers. If we don't know the start_lsn then we must assume that all 3,000 page servers could have data for the table. However with a start_lsn we could know that only a subset of the PSEs cover the table's lifetime so we don't need to propagate the event out to the others

How?
WiredTiger doesn't track the LSN anywhere and we need to build this capability. On a theory level, we could do this via adding a disaggregated.create_lsn field to the stable table's file: metadata entry (i.e., by adding it to the file_disaggregated_config in api_data.py), and then populate it automatically in __create_file from conn->disaggregated_storage.last_checkpoint_meta_lsn. This would give us an LSN that's slightly before the LSN of the previous checkpoint completion record, but it should be good enough for just bounding PS.