RFD: deterministic generated assets for storage-backed seeds

[softmarshmallow]

Context

Spock's file("./seed/...") support correctly treats a seed as a bundle of the contract plus real file bytes. That proves the storage path, but examples currently need committed binary assets.

The Uhura Instagram demo already has a small deterministic image generator driven by a text manifest (motif, seed, dimensions, alt text). The same idea is potentially more valuable for Spock examples: reproducible real bytes for storage_object seeds without hand-authoring or licensing binary fixtures.

This issue defers that design while the current Uhura↔Spock media PoC focuses on exercising today's storage contract.

RFD questions

• Should generation live in a reusable standalone crate/tool rather than coupling Spock to Uhura?
• Should assets be generated only by an explicit developer command and verified in CI, or generated during example setup?
• What manifest/versioning contract makes output byte-for-byte deterministic across tool upgrades?
• Should generated files remain committed, or should CI/runtime materialize them from the manifest?
• How should checksums, MIME types, dimensions, alt text, and generator provenance be recorded?
• How does this interact with the existing rule that file(...) paths are relative, safe, and seed-only?

Non-goals

• No change to the current storage protocol or storage_object model.
• No runtime image transformations, CDN, or production object backend.
• Do not block the current Instagram storage-backed media PoC.

Expected outcome

An RFD comparing committed binaries, deterministic generated fixtures, and a shared asset-generation tool; it should recommend a reproducible workflow plus a CI drift check and a migration path for Spock's Instagram examples.