Roll the response-shape and recipe fixes out to the components outside COMPONENTS_UNDER_TEST

Regenerate every component outside COMPONENTS_UNDER_TEST against the four generator fixes the refdata pass landed, so the tree carries one response shape and one recipe family rather than two of each.

check_component_drift.py --all regenerates exactly the components in COMPONENTS_UNDER_TEST, so a shared-template change reaches those and no others. Three of the four fixes are shared templates or shared protocol derivation:

• The protocol-dependency gate now asks whether the model has a protocol rather than whether the address under regeneration selected one. Before it, any per-space run – and the drift check regenerates one space at a time – dropped ores.doc.shell-recipe, so every component's checked-in recipes are frozen at whatever the last working generator produced. Regenerating a component refreshes its recipes and, from then on, the gate keeps them honest.
• A put response and a single-version response now carry their row in a std::optional. A component that has not been regenerated still serializes a default row when there is no row: a client refuses the whole response with Invalid date value: 0000-00-00 before it can read the outcome. ores.dq carried that shape when the refdata pass measured it; dq is now inside the set.
• A batch removal of an empty key list now answers instead of rendering an empty IN (, which the server refuses as a syntax error.

The components outside the set are now trading and workspace. Five joined the rollout below: history, scheduler, storage, marketdata and synthetic. Four others joined the set in their own passes: reporting, http-cpp, shell and refdata.

Five components are regenerated on that branch, one commit each. The table states what each regeneration changed and how many files it touched.

check_component_drift.py passes for each of the five, and the full build and the full test suite pass on the branch.

The rollout is not mechanical. A regenerated protocol can stop a hand-written caller in another component from compiling. ores.shell read put_job_definition_response::job_definition as a value; the scheduler regeneration made that field an std::optional, and ores.shell.application stopped building. The command now reads the definition through the optional and reports when the server returned none. Expect the same class of break from the two components that remain.

• trading is deliberately not regenerated on the branch. Its model holds 64 entities, and the regeneration would rewrite the whole component.
• workspace-cpp is deferred. Its regeneration is structural rather than a refresh: it materialises 30 files, 10 of them new eventing, history-provider, registrar, handler and presentation files that the component does not carry today.

That branch merged as 17fa9f47fd through PR #2334, so the five are on main and only the two above remain.

• The task that found them: doc/agile/versions/v0/sprint_26/clean-refdata/task_clean_refdata.org, item V04.
• projects/ores.codegen/scripts/check_component_drift.py — the regeneration set is COMPONENTS_UNDER_TEST in component_registry.py.
• The regression tests that pin the fixes: test_protocol_dependency_scope.py, test_version_response_optional.py, test_batch_remove_empty_guard.py.

• Clean ores.refdata to the component clean standard
• Generated recipes are stale, and nothing watched them — the full-address sweep found the same __none__ placeholder symptom and asks which side is behind. V04 answers it: the template is right, the recipes want regenerating.