refactor(mux): lay the TS export's tables from current state

quest/m1/ts-reliability/README.md

@@ -102,7 +102,6 @@ catalog linger (#5305).
 - [A timebase step restarts the TS import](/quest/m1/ts-reliability/step-restart.md) - an unflagged step or a rewind republishes under a new epoch instead of ending the import and every subscriber's export
 - [Export re-acquires a step](/quest/m1/ts-reliability/export-reacquire.md) - `moq export ts` re-acquires an unmarked timeline step instead of exiting on fake drift
 - [A restart keeps its catalog](/quest/m1/ts-reliability/restart-catalog.md) - a restarted import publishes its catalog with its first media
-- [Tables from current state](/quest/m1/ts-reliability/psi-state.md) - the TS export lays its PAT and PMT from current state when their slot comes up, with byte-identical output for a static program
 - [PAT changes](/quest/m1/ts-reliability/pat-lifecycle.md) - a running export follows a moved PMT PID
 - [A demoted subscriber priority reaches the publisher](/quest/m1/ts-reliability/stitch-catch-up.md) - a mid-stream priority demotion reaches the publisher on lite-07 and moq-transport, including an old instance after an epoch switch
 

quest/m1/ts-reliability/pat-lifecycle.md

@@ -19,11 +19,15 @@ export started after it.
 The maintainer's plan, from closing
 [moq-dev/moq#6301](https://github.com/moq-dev/moq/pull/6301): the export
 follows a new `program.pmtPid` with a new PAT, built on the table rework
-that lays the PAT and PMT from the current table state when their slot is
-laid instead of riding queued units, so a move is one more state change
-rather than a rewrite of queued copies. That rework is its own quest,
-[tables from current state](/quest/m1/ts-reliability/psi-state.md)
-(planned 2026-10-28), so this quest keeps only the PMT move and its tests.
+that lays the PAT and PMT from the current table state when a copy of them
+begins to go out, so a move is one more state change rather than a rewrite
+of queued copies. That rework has landed: the export's `Psi` holds the
+tables as they stand, `Export::restate` hands them to
+`Schedule::set_psi`, which every copy not yet begun lays, and a copy
+already on its way finishes as it began. A move then updates `Psi::pmt_pid`,
+calls `Schedule::set_tables` for the new PID, and restates; `Psi::current`
+gives the PAT the next version when the PID differs from the last laid.
+This quest keeps only the PMT move and its tests.
 
 The draft then says that `pmtPid` can change in place, and when a consumer
 rebuilding the stream moves the PMT.
@@ -36,7 +40,3 @@ old one after it, and a move while every copy is still queued goes out as
 one PAT naming the new PID. `revision_test`'s
 `a_track_recorded_on_the_pmt_pid_after_the_catalog_moves_it_takes_another`
 then pins the move instead of the PMT staying put.
-
-## Required
-
-- [Tables from current state](/quest/m1/ts-reliability/psi-state.md) - the export lays the PAT and PMT from current state, so a move is one more state change