[lightningpixel]

Summary

A manifest may declare inputs as slot objects instead of type names:

"inputs": [
  { "name": "front", "label": "Primary image", "type": "image", "required": true },
  { "name": "left",  "label": "Image 2",       "type": "image", "required": false }
]

The workflow preflight compared those objects against output type strings, so every connection looked missing and the error named the type "text" whatever it was ("Image to Image needs an incoming text connection").

• Manifest parsing (normalizeNodeInputs in extension-install-utils.ts): slot objects are reduced to their type when the manifest is parsed, both at install validation and when listing extensions. Their labels become inputLabels (explicit input_labels still win) and optional slots are carried as inputsRequired. Every downstream consumer (node handles, edges, runner) keeps receiving type names. An entry with no type is rejected with a clear manifest error.
• Preflight: a type is required only if at least one slot of that type is required; optional slot types are still accepted on incoming edges. Unknown types are named as declared instead of defaulting to "text".
• The runner already skips unconnected slots (assignSlotFilePaths), so an optional slot left empty runs fine.

Fixes #241

Test plan

• New tests in extension-install-utils.test.mjs (normalization, labels, optionality, rejection, scene-shape check on object slots) and preflight.test.mjs (optional slots, type naming). The two preflight tests fail on dev and pass here.
• npm run test:node: 0 failures
• ESLint clean on touched files; tsc reports no errors in touched files (pre-existing errors on dev unchanged)
• Manual: install an extension with object-shaped inputs (e.g. modly-Codex-image-extension), wire an image into it, and check the workflow runs and the slot labels show