Story: Hotfix: CI builds red across all OSs on value_or({}) in the generated result mapper

Main's continuous GitHub Actions builds are red on every OS. The Linux (gcc 13) and macOS (Apple clang) jobs fail to compile projects/ores.compute/core/src/repository/result_mapper.cpp. The mapper-impl codegen template emits v.<field>.value_or({}) for nullable numeric fields, and a braced-init-list cannot deduce the template parameter of std::optional<T>::value_or on those compilers. MSVC and clang-cl accept the deduction: the Windows jobs compiled the same file in the same window and were red for separate reasons (a test-seed failure and a transient file-lock link error), both since addressed. The local toolchains (g++ 16.2, clang 21.1) also accept the idiom, which is why bind PR #2012 built green locally. The fix emits an explicit value_or(0) instead, retangles the mapper template, and regenerates the compute mapper. Zero is semantically identical to {} for the two nullable numerics in play: pgmq_msg_id (nullable bigint to std::int64_t) and outcome (nullable int to int, generator default 0), both read into non-optional domain scalars. The CI builds return to green.

• The mapper-impl codegen template emits value_or(0), never value_or({}), for nullable numeric fields.
• Regenerating the compute mapper is the only drift the template change produces; the codegen drift checks pass.
• The local build, ctest and site build stay green, and the continuous CI on every OS returns to green after the merge.

• The codegen banner and drift-baseline rollout across components: the Entity classification and drift baseline across all components story owns it.
• New bind work: this hotfix changes the template and one regenerated file, nothing else.