Story: Fix rfl complexity failure (Windows + macOS CI)

ClientManager.hpp defines process_authenticated_request<T> as a function template:

template <nats_request RequestType>
auto process_authenticated_request(RequestType request, ...)
    -> std::expected<typename RequestType::response_type, std::string> {
    using ResponseType = typename RequestType::response_type;
    // ...
    auto result = rfl::json::read<ResponseType>(raw);  // <-- instantiated in CALLER'S TU
    // ...
}

Because the body is in the header, every .cpp that calls this template compiles rfl::json::read<ResponseType> into its own translation unit. MSVC tracks a "template dependency graph" per TU: all rfl::StringLiteral<N> field-name types from every rfl::json::read<X> instantiation accumulate in that graph.

C1202 fires when two conditions coincide:

1. The caller TU already has a saturated dependency graph. A file compiled late in the build (e.g. BookMdiWindow.cpp at step 4651/4936) includes many headers. Each header's templates — not just rfl — add nodes to MSVC's dependency graph. By the time compilation reaches the process_authenticated_request call, the graph is already large.
2. The ResponseType contains trade_instrument (or another type whose rfl reflection chain reaches swap_leg or another struct with 15+ fields). Adding even 19 new StringLiteral<N> nodes (one per swap_leg field) is enough to push the graph over MSVC's internal limit.

Neither condition alone is sufficient. The pattern is invisible on Linux (GCC has more permissive limits) and only surfaces on MSVC for callers that are large enough.

The rule: a call site is at risk if RequestType::response_type contains trade_instrument (directly or via trade_export_item) and the calling file is large enough to saturate MSVC's dependency graph.

Step 1 — find all response types containing trade_instrument or trade_export_item:

grep -rn "trade_instrument\|trade_export_item" \
    projects --include="*.hpp" | \
    grep "struct\|vector\|instrument " | \
    grep -v "build\|vcpkg\|//\|domain/"

Step 2 — from those types, identify which are response_type aliases of a request type that is passed to process_authenticated_request:

grep -rn "process_authenticated_request\|process_request" \
    projects --include="*.cpp" | grep -v "build\|vcpkg\|test"

Then cross-reference the inferred request type at each call site with the request type's response_type.

Current audit result (2026-06-02):

Only export_portfolio_request is at risk. get_trade_instrument_request also carries trade_instrument in its response_type, but it is handled by parse_trade_instrument() directly and is never passed through process_authenticated_request.

For any process_authenticated_request<T> call site where T::response_type contains trade_instrument: replace it with a concrete (non-template) method on ClientManager, implemented in a dedicated .cpp file. This isolates the rfl::json::read<ResponseType> instantiation to a fresh TU where MSVC's dependency graph starts clean.

Pattern used in this story: parse_swap_instruments.cpp, ClientManagerExportPortfolio.cpp.

Through sprint 17, 18, and 19 these errors have been treated as one escalating problem. Error 7 makes clear they are two separate failure modes with different fixes.

Problem A — struct field count exceeds MSVC's threshold.

rfl::internal::no_duplicate_field_names builds an rfl::Literal<f1,…,fN> for every struct it reflects and performs an O(N²) constexpr string-equality check. With N ≥ ~15 this check exceeds MSVC's internal template dependency graph budget regardless of TU size or context. Error 7 proves it: ClientManagerExportPortfolio.cpp fires at step 1145/4938 with exactly two includes. TU isolation does not help when the struct itself is above the threshold.

Problem B — rfl in header templates leaks to caller TUs.

process_authenticated_request<T> is a function template defined in the header. Every caller TU instantiates rfl::json::read<ResponseType> in its own translation unit. In large, late-compiled files (e.g. BookMdiWindow.cpp at step 4651/4936) the already- saturated template dependency graph cannot absorb the additional rfl::StringLiteral<N> nodes from swap_leg's 19 fields. The "concrete method in dedicated TU" fix addresses this.

The seven-incident cascade is not seven separate bugs. It is one structural problem (struct fields exceed MSVC's threshold) repeatedly re-encountered after each partial fix removes the immediately visible symptom:

Every persisted domain struct carries five audit fields: modified_by, performed_by, change_reason_code, change_commentary, recorded_at. These are invisible in domain terms but consume five slots in the rfl Literal. A struct that appears to have 10 domain fields is 15 to rfl. Any domain struct across ores.refdata, ores.assets, ores.trading, ores.iam, ores.dq, etc. that has ≥11 non-audit domain fields is silently above the MSVC threshold. There is no compile-time guard or lint rule to catch this; discovery is always reactive (CI failure).

The proactive audit in the "template instantiation leak" section above was a Problem B audit — it checked which process_authenticated_request response types contain trade_instrument. A Problem A audit would check which domain structs have ≥~15 fields, irrespective of how they are called. That audit has not yet been done for the full domain model.

Extract the five audit fields into a shared sub-struct and compose it into every domain struct via rfl::Flatten:

struct audit_info {
    std::string modified_by;
    std::string performed_by;
    std::string change_reason_code;
    std::string change_commentary;
    std::chrono::system_clock::time_point recorded_at;
};

struct swap_leg {
    // up to ~13 domain fields
    rfl::Flatten<audit_info> audit;   // 5 fields; checked independently by rfl
};

rfl::Flatten projects sub-struct fields directly into the parent in JSON (no nesting), so the on-wire format is unchanged. no_duplicate_field_names checks each sub-struct independently: O(5²) = 25 comparisons for the audit group instead of O(N²) for the full struct. The safe domain field budget per struct is then ~13 non-audit fields, which comfortably covers all current domain types.

This systematic extraction is not yet scheduled as a story; task 9 applies it locally to swap_leg. A cross-cutting story would audit all persisted domain structs and apply the same pattern project-wide, permanently closing the structural risk.