Manga lane: emit and persist a manga_manifest artifact

[pro-utkarshM]

The gap

technical-imp.md §13.1 defines the chain:

PDF -> Manga -> MangaManifest -> ReelSpec[] -> Remotion

After d0c2315 the workflow emits context_pack, manga_plan, asset_request_set, rendered_page_set, and memory_delta. manga_manifest is never produced — MangaManifest exists only as a contract in backend/app/contracts/manga.py.

Consequence: ReelPlayerService._load_series_state reads accepted ReelSpec artifacts and their manifest, so list_accepted_reel_specs(project_id) returns empty for every real project. Reel discovery is honestly empty rather than broken, but the golden flow in §19.6 cannot complete, and the reel player stays fixture-only.

The ask

§12.2 step 7 already assigns this to the manga lane:

• Persist RenderedPage as the single public reader contract.
• Derive and persist MangaManifest.
• Propose a MemoryDelta.

Concretely, at the end of MangaProductionService, after rendered_page_set is accepted:

1. Derive a MangaManifest from the accepted MangaPlan + RenderedPageSet. The contract exists; the derivation is a projection, not new generation — panels, beats, dialogue, narration, visual_asset_ids, crop_hints, and source_refs are already carried by those artifacts. No LLM call, no paid provider.
2. Persist it as an artifact of kind manga_manifest, with the RenderedPageSet and MangaPlan as parent_artifact_ids.

What is already built on the other side

deriveReelSpecs(manifest, { mangaManifestArtifactId }) landed in packages/reel-components/ (#7). It is deterministic — no model call — and turns a MangaManifest into schema-valid ReelSpec[]. It has been verified end to end against fixtures: derive → compileReel → real Chromium render at 1080x1920.

So once a manga_manifest artifact exists, wiring reel generation is: call deriveReelSpecs, persist each result as a reel_spec artifact. The reel delivery API and player already consume those.

Open question for whoever picks this up

Where should the deriveReelSpecs call run? Options:

1. A Celery stage in the control plane calling into the Node side, consistent with how agent_worker is already invoked (§9.6).
2. Inside apps/agent-worker/, which already has the Node runtime and would be the natural home for the Pi Reel Director later (§13.2).

(2) is probably the better long-term seam since the Reel Director replaces deriveReelSpecs behind the same signature. Both directories are core-lane owned per AGENTS.md, so this is Mrigesh's call.

Ownership

backend/ and apps/agent-worker/ are core-lane per AGENTS.md. Filing rather than implementing, per the shared-seam rule: request states the artifact, the consumer, and a fixture example.

Fixture example: packages/fixtures/canonical/manga_manifest.v1.json.

[pro-utkarshM]

Reel side is built and up for review in #7: deriveReelSpecs turns a MangaManifest into schema-valid ReelSpec[] deterministically, plus render receipts and audio.

That PR runs on fixtures only. The moment a manga_manifest artifact is persisted, wiring reel generation is: call deriveReelSpecs, persist each result as a reel_spec artifact. The reel delivery API and player already consume those.