Task: Migrate the storage consumers onto the shared interface

Every component that moves bytes calls the storage interface rather than its own copy of it, and the copies go. One HTTP client, one archiver and one set of key builders remain in the tree, the shell's storage verbs are the raw surface rather than five verbs named after their callers, and no consumer reaches storage through a hand-rolled path, key or retry loop.

The buckets stay the consumers' business: each names its own, and nothing in storage needs to learn the names for the migration to work.

• ores.compute.wrapper links the storage interface and its own HTTP client and archiver are deleted, including the download path that opens its destination before it reads the status.
• ores.ore and ores.reporting reach storage through the interface, and the report-data bucket name each of them duplicates lives in one place per component rather than in two anonymous namespaces.
• The shell exposes the raw surface — a bucket, a key and a local path — and the consumer verbs (ore upload, compute publish-package, compute download-input, compute download-output) are thin wrappers over it.
• The base URL is plumbed one way, not three, and no service defaults to a port the server does not listen on.
• A grep for a second Beast client, a second libarchive archiver or a hand-built storage path outside the component returns nothing.

(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.