Task: Scaffold story: Run an example bundle through the compute grid from a report definition

(Describe what user-visible-or-internal change this task produces.)

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

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.

Delivered. The story, its investigation and five tasks are scaffolded and wired into Sprint 26, and the sprint table agrees with the story file.

The analysis changed the story's shape and is the reason the investigation exists. The intended reading was seeding: a report type, a definition, a bundle, done. It is not. The step chain is registered once in C++ and the trigger hard-codes its type, so no definition can run a shorter chain today; and the reporting to compute handoff cannot drive a job at all — it publishes on a subject no wrapper subscribes to, leaves result_id, package_uri, config_uri and output_uri empty, and hands over a bucket-prefixed URI where the wrapper fetches an HTTP path.

Two things were settled and one is owed. Settled: the handoff fix is in scope although the code is in ores.compute, and retrieval is in scope while parsing results is not. Owed: whether the run executes the vendored ORE example bundle or the reporting chain's own blobs, since the chain packages the latter and the engine needs the former.

One duplicate was removed: the story scaffold creates a first task, and a task with the same title was then created deliberately, so the auto-created one was deleted and its row dropped. There is no compass verb for that; it is the only hand-edit in this story.