[guyverino]

What & why

The live feed publishes every core's whole order list twice: as the order table (FeedMsg::Orders, every 250 ms when an order changed) and, for the chart, as line copies (FeedMsg::OrderLines, leading edge then at most every 50 ms). A headless station has no chart, yet it built and applied both. In a station CPU report from a 70-core user (#1081) the order messages were 96–99 % of the main thread, and the line copies were the larger part.

On a station a line event now puts the table in debt instead (OrderDebts::of_turn, feed/live/publish_gate.rs). The turns captured for the copies keep being captured and ride the next table, so an order removed between two tables still reaches the store, as it did through a copy. The terminal is unchanged.

Measured on our 27-core station with the Mini App on, A/B in one process (the mode alternated every 5 minutes, two cycles each, first minute after start excluded):

per minute	copies on (before)	copies off (after)
order tables	~4,700	~4,800 (+2 %)
line copies	~9,400	0
order rows built	742k	238k
row building, feed threads	4.07 s	1.40 s
applying, main thread	2.79 s	1.20 s
process CPU	13.0 s	9.0 s (−31 %)

The measured build was based on 5cce1f02, before #1141, which made applying both kinds of message cheaper; the saving on top of #1141 is therefore somewhat smaller on the apply side, and unchanged on the row building.

Notable decisions

• The station's order-line store is still read on the station: the Mini App's Panic Sell state (panic_snapshot_armed) and the clock-skew estimator. Both now see an order change within the table's 250 ms instead of ≤50 ms. A Panic Sell pressed in the Mini App still shows at once through the optimistic override (3 s TTL); one toggled in the core shows up to ~200 ms later. Nothing on the trading side moves: the station only re-reads what the core already sent.
• No switch: a station has no consumer that needs the 50 ms cadence.

Known limitations

• The table count rose by 2 %; trace-point-only turns now owe a table on a station.

Issues

Refs #1081 — CPU of the station's order path; the out-of-memory cause in #1081 is still open.

How to verify

cargo build -p moon-ui-gpui --bin moonterminal --target x86_64-pc-windows-msvc --all-targets
cargo fmt --all -- --check
cargo clippy --workspace --all-targets --locked --target x86_64-pc-windows-msvc -- -D warnings
cargo test --workspace --target x86_64-pc-windows-msvc

fmt exit 0, build exit 0, clippy zero warnings, 8556 tests green (three new in publish_gate/tests.rs). Live: a station build carrying this change has run on our station since 10:14 UTC: 27/29 cores ready as before, no panic, no slow main-loop pass.