Story: Hotfix: Continuous Windows MSVC jobs red on C4275 in the exported exception classes

Continuous Windows is red on main, and it has been red since 2026-09-04. The workflow runs four jobs. Two use MSVC and two use clang. Each pair fails for its own reason, and this story covers the MSVC pair.

The MSVC jobs stop in the compile of ores.platform with error C2220. That error is not a defect of its own. The compiler raises warning C4275, and /WX promotes the warning to an error. C4275 reports that an exported class derives from a base class with no dll-interface. The exported classes here are ores::platform::filesystem::io_error and file_not_found, and their bases are std::exception and boost::exception.

The project already suppresses the sibling warning C4251 on the same grounds, one line above where C4275 fires. This story extends that suppression.

• The MSVC jobs reach their build and test steps instead of stopping at C2220.
• The suppression sits beside the existing C4251 suppression, under the same MSVC generator expression, with a comment that gives the reason.
• The clang jobs on the same workflow are unaffected by this change.
• The code class checks pass.

• Suppress C4275 rather than redesign the exception classes. The reason is the one already recorded against C4251. Every consumer is an in-tree target built by this same toolchain against these headers, so the ABI mismatch the warning exists to catch cannot arise here. Deriving from std::exception is the right design for these types, and dropping the base class to please the warning would make them worse. The suppression and its comment sit beside the C4251 pair, so the two read as one decision.
• The change lands alone. The clang jobs on the same workflow fail for an unrelated reason, and that reason has its own home.

• The two clang Windows jobs, which stay red. They stop on LLVM ERROR: out of memory while compiling the add verb of the commodity and credit instrument command units. Those two verbs take 32 and 25 typed positional parameters, and cli::Menu::Insert expands one template instantiation per argument. The 22 generated trading units take a single std::vector<std::string>, so they do not expand. Converting the two hand-written units by hand is not worth the effort, because the port of the hand-crafted trading instruments to codegen produces that shape on its own. That work is Port trading instruments to codegen.