[guyverino]

What & why

Moves the moonproto pin from 98420c6d to b5319770 (Cargo.lock only; the two moonproto/polling source hashes, edited by hand so unrelated windows-sys versions stay put). Upstream's commit answers the station CPU profile from MoonProto#17: owned UDP payloads instead of copies on the receive path, an Engine API response parsed once and reused, a direct server-index → local-position table for market price updates (+~16 KB per 1000 markets per client), and MarketsState::find without allocations. moonproto's own dependencies and the Compact 30 ms idle wait are unchanged.

Measured on our 28-core station with the same probe as #1149 (idle wait alternating 15/30 ms in one process), moonproto runtime threads at 50k datagrams a minute, fitted against the datagram rate:

	98420c6d	b5319770
15 ms	6.43 s/min	5.66 s/min (−12 %)
30 ms	5.12 s/min	4.71 s/min (−8 %)
marginal cost per 1000 datagrams, 30 ms	0.032 s	0.020 s (−38 %)

MoonTerminal's own feed threads are unchanged (~2.65 s/min). The two runs were on different evenings and built with cargo zigbuild (Zig's libc allocator), so the release build is where the final number comes from.

Notable decisions

• No MoonTerminal code calls MarketsState::find; CatalogLookup uses search, which upstream left as it was.

Known limitations

• Whole-process CPU did not move outside its spread between the two evenings: tape donors, valuation and the feed threads vary more than the moonproto saving.

Issues

Refs #1081 — station CPU; the out-of-memory cause stays 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, 8776 tests green (TEMP on a drive with at least 10 % free).