Task: Implement Hotfix: Domain generator omits the Boost UUID I/O include

The generated synthetic generator for an entity whose generator_expr calls boost::uuids::to_string must compile. Today it fails because the domain-entity generator template emits no <boost/uuid/uuid_io.hpp> include. run_grant is the first entity to hit this.

• run_grant_generator.cpp includes <boost/uuid/uuid_io.hpp> and compiles.
• The include appears only when a generator_expr calls boost::uuids::to_string.
• The tangle reproduces the edit and no other mustache changes.
• projects/ores.codegen/tests passes.

1. Diagnose: the failing file is generated from cpp_domain_type_generator.cpp.mustache, which tangles from ores.cpp.generator.generator_impl.org. The domain_entity section never includes <boost/uuid/uuid_io.hpp>; the junction section already gates that include on has_uuid_left_or_right.
2. Add has_uuid_to_string_generator in projects/ores.codegen/src/codegen/core.py. The flag is true when any generator_expr – the primary key, its extra columns, a natural key, or a column – calls boost::uuids::to_string.
3. Gate #include <boost/uuid/uuid_io.hpp> on the flag in the org source.
4. Re-tangle the mustache with compass build --direct tangle_codegen_templates.
5. Regenerate the entity with compass codegen regenerate --component iam --entity run_grant --address ores.cpp.generator.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Root cause: cpp_domain_type_generator.cpp.mustache renders a model's generator_expr into the domain-entity section, but that section lists no <boost/uuid/uuid_io.hpp> include. The junction section of the same template already gates that include, because a junction's generator expressions call boost::uuids::to_string. The run_grant model's resource column is the first domain-entity generator_expr to call it.

Fix: the new has_uuid_to_string_generator flag in core.py mirrors the junction's has_uuid_left_or_right gate. The template emits the include only for an entity that needs it, so no unrelated include lands in the other generated generator files.

The mustache is tangled output. The durable edits are in ores.cpp.generator.generator_impl.org and core.py; the mustache was re-tangled, not hand-edited.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The generator template emits <boost/uuid/uuid_io.hpp> only when a generator_expr calls boost::uuids::to_string, and run_grant_generator.cpp carries the include. ores.iam.api.lib builds, the codegen suite passes (1158), and the iam component has no drift. Merging PR #2689 clears the CI failure.