fix(settings): send the global blacklist through the compact channel

[guyverino]

What & why

A user reported: a coin added to the core's global blacklist via the Telegram bot, then removed in MoonTerminal, stayed blocked — the core's log kept saying match global black list while its own window and every settings echo showed the coin gone; adding and removing it again in the core's window fixed it.

Reproduced on a live core with a strategy whitelisted on one coin as the probe. The gear popup and the expert window wrote the blacklist (use_coins_black_list / coins_black_list_text) as part of the full safe-share packet (TSharedConfigCommand). The core stores that text and echoes it back but never rebuilds its per-market "blacklisted" flag from it. The core developer confirmed that the compact TClientSettingsCommand is the path that calls RebuildMarketsBL — the path the coin context menu already used.

Both surfaces now send the two fields through CoreCmd::SetBlacklist ahead of the page; the safe-share applier leaves them alone, so the packet carries whatever the core holds when it is built.

Notable decisions

• Sent only when the surface's own user changed the list, judged against the page the surface was seeded from (popup: its seed; expert window: the live page before the staged fields were overlaid). The draft is frozen once touched, and the list is one string: an OK on the leverage row would otherwise carry the frozen list out and undo a coin added meanwhile from the context menu, a second terminal or the core's Telegram bot — and, now that the core acts on this channel, undo it for real.
• The safe-share applier no longer writes the two fields at all (apply_general), for the same reason: with the blacklist owned by one channel, the page cannot paint the core's echo over with a stale copy. The round-trip test now asserts the field does not pass through.
• Compact first, page second: the safe-share queue waits for the compact echo before building its packet from the retained snapshot, so the page carries the post-edit text. When nothing else changed, the queue finds the page already satisfied and sends no TSharedConfigCommand at all.

Known limitations

• The compact queue has no echo timeout (its documented KNOWN LIMIT): a core that never echoes ClientSettings parks the safe-share writes behind it for the connection. This change adds no new exposure beyond what the coin context menu already had, and only on an actual blacklist edit; a timeout in that queue is a separate change.
• The core-side defect (TSharedConfigCommand not rebuilding the market flag) is not fixed here and, per the core developer, not planned; the terminal avoids the path instead.

Issues

None of the 17 open issues is touched by this change.

How to verify

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

fmt --check exit 0; build pass; clippy: no finding in the touched files (pre-existing debt elsewhere unchanged); moon-core 1955 passed, moon-ui-gpui 1810 + theme_contract 333 passed, 0 failed. FireTest not run — no chart/render/window/input surface.

Live: on a core with a coin blacklisted and a strategy whitelisted on it, removing the coin in the gear popup → compact packet sent → core echo without the coin → core Global BL: line → both strategies placed buys 0.7 s after OK; the safe-share packet was not needed. Twice. The reverse edit in the core's own window cancelled those orders with match global black list.

🤖 Generated with Claude Code