Task: Implement Hotfix: a visibility macro on an enum breaks the Windows build

Make the Windows clang-cl build compile the workflow definition again, and close the gap that let the defect reach main.

• enum class failure_policy : std::uint8_t declares the enum with no visibility macro, and the header still compiles.
• ores.workflow.api, ores.workflow.core, ores.workflow.service and ores.dq.core.lib build, and the workflow suites pass.
• check_enum_export_attributes.py exits 0 on the tree, naming how many enum declarations it read, and exits 1 on a tree where the macro is back on the enum, naming the file and the line.
• The check runs in a pull-request workflow that fires on any change under projects/.

1. Scan the tree for the shape and confirm the one site.
2. Reproduce the platform behaviour: what clang-cl reports, and what clang and gcc on Linux report for the same declaration.
3. Drop the macro, add the comment that says why, and rebuild.
4. Run the workflow and dq suites.
5. Write the check, prove it in both directions, and wire it to a workflow.
6. Record the story, the task and the sprint row, then raise the pull request.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at.

• The exact diagnostic is quoted from the CI log of a Windows clang-cl job: error: '__dllimport__' attribute only applies to functions, variables, classes, and Objective-C interfaces [-Werror,-Wignored-attributes]. It cannot be reproduced on Linux, because __dllimport__ is the Microsoft spelling of the attribute and clang on a Linux target does not know it – the local probe reports -Wunknown-attributes instead. That is itself the point: the macros expand per platform, and the platform that rejects the attribute is the one no pull request builds.
• The attribute is harmless where the compiler accepts it, which is why this survived review. cppreference is plain that dllimport applies to functions, data and classes, and neither MSVC nor clang-cl documents it on an enum; clang-cl is simply the only toolchain in the matrix that says so and the estate builds with -Werror.
• An enum needs no import or export attribute. failure_policy travels across the boundary as a std::uint8_t, and every other enum in the estate is declared without a macro.
• The check reads projects/ only, which is where every C++ source and every visibility macro in the estate lives: the export.hpp of each component defines its macro and the headers use it.
• The check blanks comments before it scans, so a comment that describes the rule does not violate it. The comment left on the declaration is exactly such a comment.
• The first full test run failed five suites on column "oresmd_uri" does not exist, which is the local database rather than the tree: it was created before that column reached the schema. A compass db recreate -y -k took the suite to 89 of 89, including ores.refdata.core.tests, which was the one failure recorded on main earlier in the sprint. No code changed between the two runs.

workflow_definition.hpp declares enum class failure_policy : std::uint8_t with no visibility macro, the comment above it says why, and the tree builds. The full suite passes 89 of 89 on a recreated database.

build/scripts/check_enum_export_attributes.py reads 421 enum declarations in 294 files, finds no visibility macro on any of them, and fails on a tree where the macro is restored, naming the file and the line. .github/workflows/header-hygiene.yml runs it on every pull request that touches projects/.

Continuous Windows is dispatched against this branch, run 36566068366, to see the clang-cl diagnostic disappear on the platform that reported it. That run takes hours, so it is recorded rather than awaited: the translation unit that failed, ores.dq.core.lib, compiles on Linux with the same header, and the known ores.shell.trading limit is the next thing the Windows build reaches.