Task: Retire the rfl complexity flags and close the variant traps

projects/ores.trading/api/src/CMakeLists.txt sets, PUBLIC: /constexpr:depth100000 and /constexpr:steps10000000 for MSVC, and -fbracket-depth=1024 for $<CXX_COMPILER_ID:Clang>. The comment beside them names rfl::AddTagsToVariants, which is no longer called anywhere.

Measured on this branch with -fsyntax-only and the flag overridden. Every TU on the export path compiles at bracket depth 128, and so at AppleClang's default of 256: instrument_payload.cpp, domain_instrument_payload_tests.cpp, messaging_export_portfolio_codec_tests.cpp, registrar_trades.cpp, ClientManagerExportPortfolio.cpp and exporter.cpp.

So the flag is not what keeps macOS green any more. It is also not what keeps MSVC green: /constexpr:depth and /constexpr:steps have no effect on C1202, which is a limit on the template instantiation graph. The flags are harmless but they are now a claim about the code that the code no longer makes. Removable, subject to the full-consumer sweep in the acceptance.

trade_protocol.hpp:100 still holds ores::trading::domain::trade_instrument instrument. This was left alone deliberately: its only consumer, ores.qt.headless/parse_trade_instrument.cpp, dispatches on (product_type, trade_type) and decodes one known concrete leaf per instrument, so it never asks reflect-cpp to guess an alternative, and converting it would force a Qt parser rewrite.

The hazard is therefore latent, not live: any future consumer that decodes this response monolithically will get std::monostate for every instrument, silently. The sprint 25 defect was exactly that. Either convert it or say so at the declaration.

MSVC C1202 fires in rfl/internal/no_duplicate_field_names.hpp when the field count of a single reflected struct is large enough. The threshold is known from sprint 19 (PR #1031, Fix C1202 in ClientManagerExportPortfolio.cpp): swap_leg at 19 fields fired it in a clean TU, and was fixed by decomposing into three sub-structs of at most 9 fields behind rfl::Flatten.

bond_instrument_data carries 28 members. It is reflected on the export path, because the payload encodes the whole leaf as JSON. That is above a count already known to be fatal, so Windows is expected to fail there. This was not introduced by the payload change: trade_export_item held the same variant, and therefore the same reflection, before it.

Not measured, because nothing on this host runs MSVC, and Windows CI is out of scope for the round-trip work. The fix, if it is needed, is the sprint 19 one: split the container into sub-structs behind rfl::Flatten.