fix(media-use): ingest derived video outputs

[miguel-heygen]

What

• allow video as an ingest-only resolve --from media type
• default extensionless video ingests to .mp4
• add an end-to-end resolve regression that verifies the manifest and .media/video path

Why

references/operations.md documents resolve --from talk.cut.mp4 --type video, and the manifest already owns a video subdirectory, but the CLI rejected video because provider-backed resolve types and ingest types shared one validation list.

Reproduction

Confirmed on 0.7.55: resolve --from derived.mp4 --type video exits 2 and lists types without video.

Verification

• resolve engine: 31 passed
• manifest/cache: 24 passed
• registry: 14 passed
• formatting and git diff --check pass

[james-russo-rames-d-jusso]

Reviewed at 0ee302e5.

Small, correct unblock. The provider-backed types (listTypes()) legitimately shouldn't include video (there's no provider that "resolves" a video from a prompt/entity — you always bring your own file), but ingest-only shape via --from is exactly the right escape hatch, and the manifest already owned the .media/video/ subdir + nextId sequence so no downstream plumbing needed. .mp4 default is a sensible bias for the extensionless-source case (uncommon but real for pipelines that emit derived outputs without keeping extensions).

Verified REGISTRY in registry.mjs is a static object literal populated at parse time (not via side-effect imports), so listTypes() returns stable keys regardless of when it's called — the const INGEST_TYPES = [...listTypes(), "video"] computation is safe. And ES module import hoisting means all imports (including those after line 23) resolve before the const declaration executes.

The sibling unknown type error lists grade and lut test at resolve.test.mjs:388 isn't affected because it uses --type bogus without --from — different code path, different error message.

Nits

• 🟡 const INGEST_TYPES = ... at resolve.mjs:23 is placed between import statements (after cube-validate at 21, before grade-analyzer at 24). Correct under ES module hoisting semantics but stylistically unusual — a reader unfamiliar with the hoisting rules could reasonably suspect a stale-listTypes() bug (I initially did). Moving the const below the entire import block would keep the "all imports first, then executable code" convention that most codebases (and eslint-plugin-import/first) enforce, at no correctness cost.

LGTM.

— Review by Rames D Jusso

[miguel-heygen]

move INGEST_TYPES below the complete import block

Addressed in 1b627e231: all imports now precede executable initialization, and the skills manifest was regenerated. Evidence: resolve harness 31/31; generated manifest check; targeted format check.

[james-russo-rames-d-jusso]

R2 reviewed at 1b627e23, delta from R1 head 0ee302e5.

R1 style nit addressed — INGEST_TYPES = [...listTypes(), "video"] now sits AFTER the import block at resolve.mjs:38 instead of between imports. Manifest hash regenerated. Behaviorally identical (ES module import hoisting made the prior placement functionally correct), just conventional now.

LGTM from my side.

— Review by Rames D Jusso

[jrusso1020]

Approving on Rames-D's go (R2 delta clean, nit round addressed) + Magi's CI-green confirmation. Verified at final head 1b627e23: CI green, no changes-requested, mergeable.

[james-russo-rames-d-jusso]

R3 reviewed at c17bc357, post-merge with main. Delta from R2 head 1b627e23.

Merge-conflict resolution touches only the generated skills-manifest.json hash for media-use — regenerated to 14d15dedf7acd4ed after main's own media-use changes (#2257) landed. The substantive resolve.mjs diff (INGEST_TYPES const below imports + !INGEST_TYPES.includes(type) gate in ingest + DEFAULT_EXT.video = ".mp4" + regression test) is byte-identical to R2.

LGTM from my side.

— Review by Rames D Jusso

[jrusso1020]

Re-approving on Rames-D's R3 go. Post-merge head c17bc357 is byte-identical to R2 except the regenerated skills-manifest.json hash; CI green, no changes-requested.