[guyverino]

What & why

Two commits, both station CPU work from #1081 and MoonProto#17.

1. Pin moonproto 73b3b4ef → 98420c6d. Upstream's only change: a Compact market-history client waits 30 ms instead of 15 ms on an idle socket, and MarketsState::markets_version() becomes public. Every station client is Compact; the terminal (Auto, 5 ms) is unaffected. Only the two moonproto/polling source hashes move in Cargo.lock — a plain cargo update -p moonproto also shifted unrelated windows-sys versions, which this lock avoids.
2. Coin cache keyed on the snapshot's markets_version. MarketDataSource::resolve_market read the provider catalog twice — search_markets and market_labels, each from its own snapshot. Both now run on one snapshot through CatalogLookup (market/source/catalog_lookup.rs); resolve_market delegates to it and market_labels shares the same per-market label rule, so every caller's answer is unchanged. The tape catch-up listing's CoinMarkets adds that snapshot's markets_version to its key and caches "not found" again: perf(station): resolve each listed coin's market once per catalog revision #1143 had to search refused coins every time, because the feed's catalog revision moves only when the feed thread drains the market-list event, a moment after the snapshot already holds the new list.

Measured on our 28-core station (same process, idle wait alternated every 5 minutes, ~35k datagrams a minute both ways):

	15 ms	30 ms
process CPU per minute	10.23 s	8.99 s (−12 %)
moonproto runtime threads	5.72 s	4.59 s
idle-socket wakes per minute	125k	69k
a queued command's wait, avg / max	7.2 / ~15 ms	13.9 / 30.9 ms

Notable decisions

• catalog_revision stays in the cache key beside markets_version: moonproto documents that a list apply which only changes known markets may leave the version where it was.
• The snapshot is read once per row; that read is counted in the listing's X s resolving figure.
• The 30 ms wait means a Mini App command on a quiet connection reaches the core up to ~15 ms later than before.

Known limitations

• No test pins that lifecycle.rs puts markets_version into the key: moon-core has no fixture for a live MoonClient snapshot. The label and pick rules stay covered by label_tests.rs, and the listing log line's market searches shows the effect on a running station.
• The CPU figures above come from a cargo zigbuild station, whose allocator is Zig's libc rather than musl's; they compare 15 against 30 ms, not against a release build.

Issues

Refs #1081 — station CPU; the out-of-memory cause it tracks 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, 8644 tests green (TEMP on a drive with at least 10 % free: trade_cache::full_compaction_preserves_queued_inserts refuses to VACUUM below the disk reserve).