fix(producer): resolve template sub-composition entries in the shared compile stage - #7217

What

Rendering a <template>-wrapped sub-composition alone (entry file such as compositions/sting.html) through the distributed planner now works. The mounted-shell extraction moves from renderOrchestrator.ts into runCompileStage, which both the in-process renderer and plan() already call.

Why

plan() set htmlPath = join(projectDir, entryFile) and compiled the raw file. A template entry has no live root, its script never runs, so the probe found no timeline and no duration. Production symptom (render service, /v2/distributed/plan-s3, 500 INTERNAL_ERROR, found by Cut Room's hf_render composition= "render alone" preview):

[FrameCapture] Composition has zero duration.
  Runtime ready: true, __player: true, __hf.seek: true, GSAP timeline: false, data-duration: not set

Only the in-process path handled this (extractStandaloneEntryFromIndex in renderOrchestrator.ts), so the two lanes had diverged. Before the fix, the new plan test reproduces exactly this error (browser probe, "root duration unknown").

Related work

None linked (found from a Cut Room walk, not a filed issue).

How

• resolveEntryHtmlPath (new, exported from compileStage.ts): index entries and non-template files return join(projectDir, entryFile) unchanged; a template entry is isolated inside the project's index.html shell via extractStandaloneEntryFromIndex, written to <workDir>/standalone-entry.html, with the same two errors as before (no index.html; not mounted by a data-composition-src host). Nothing is keyed to one file name or tag shape; it derives from isTemplateEntry and the mount host.
• runCompileStage derives the path itself, so htmlPath is removed from CompileStageInput: a caller can no longer skip the resolution. The orchestrator block is deleted and plan.ts drops the argument. Both callers keep their own entry-file-exists checks and error text.
• Money/DB: none.

Test plan

Run from packages/producer:

• bun test src/services/distributed/plan.test.ts — 73 pass, 1 fail. The failure is stitched mp4 plans > locks each ProRes profile's preset and pixel format into a mov plan, a 120 s timeout in a mov/ProRes plan test that does not touch entry resolution; I did not confirm it on origin/main, CI will show.
  • New: plans a template-wrapped sub-composition alone and gets totalFrames 90 (3 s at 30 fps); rejects a template entry that index.html does not mount. Both fail before the fix with the zero-duration error above.
• bunx vitest run src/services/render/stages/compileStage.test.ts src/services/render/stages/compileStage.mediaType.test.ts — 21 pass, including new resolveEntryHtmlPath cases (plain entry untouched and no wrapper written, non-template sub-composition untouched, template isolated in the index shell, unmounted refused, no index.html refused).
• bun run typecheck in packages/producer — clean. oxlint and oxfmt on the 6 changed files — clean.
• Index entry unchanged: planning an index.html project before and after gives identical planHash (daa0ae639e3e8518656c0d1f8d9bc9d2ef904229ae2715cd0dcbdd258e593fea) and identical compiled/index.html sha256 (209fe53bd0180ccc4936eec2874d7d492f503f9104dcab990b5e61154ebf85ad).
• The in-process path is the same code moved verbatim (same messages and log line); there was no in-process template-entry test in the producer, so the new resolveEntryHtmlPath tests now cover it for both lanes.

Not exercised:

• No render of a real DEV project and no chunk-worker or Lambda run; only plan-time compile.

• scripts/check-comment-citations.mjs and scripts/comment-ratchet.mjs could not run locally (this box's git lacks check-attr --source); CI runs them.

• Template entry with a probe-time (non-static) duration was not exercised; the fixture declares data-duration.

• The published @hyperframes/producer version the render service pins needs a release before consumers see the fix.

• Unit tests added/updated

• Manual testing performed

• Documentation updated (if applicable): no user-visible CLI flag or command change

• Comments follow CONTRIBUTING.md "Comments"

— Jerrai