fix: validate skills/agents/extends are lists (#12)

[vessux]

Closes #12

Problem

loadManifest validated that hooks and mcps are lists of strings, but skills, agents, and extends were cast as string[] with no runtime check. A YAML scalar (e.g. extends: good, skills: local/demo) survived the cast as a plain string and was iterated character-by-character downstream:

• umbel list crashed with an uncaught TypeError: …join is not a function (list.ts:58), blocking the entire listing.
• umbel build reported nonsense per-character parents/refs (extends missing parent 'g', nine skills/<char> refs).

Fix

Apply the same Array.isArray(...) && every(typeof === "string") guard already used for hooks/mcps to extends, skills, and agents, throwing a single actionable UsageError:

• extends → 'extends' must be a list of names
• skills / agents → '…' must be a list of qualified <source>/<name> refs (wording matched to the hooks/mcps precedent, since these are the same kind of source-qualified ref)

Discovery (discover.ts:46-50) already catches a throwing loadManifest and marks the bundle malformed, so umbel list no longer crashes — it now treats the scalar bundle exactly like a bad-shape hooks/mcps bundle.

Acceptance criteria

• A scalar skills/agents/extends produces a single "must be a list" validation error.
• umbel list does not crash on a parseable bundle with a scalar field (treated as malformed).
• A correctly-formed list (extends: [good]) still works (verified end-to-end).
• Tests cover scalar inputs for all three fields (plus list-with-non-string-element coverage for the every clause).

Out of scope

How malformed bundles are displayed/surfaced in list/build (tracked in #6) is unchanged — a malformed bundle surfaces as "not found" on build, matching the pre-existing hooks/mcps behavior.

Verification

• npm test → 347 passing (+3 new)
• tsc --noEmit → clean
• biome check . → clean
• Manual e2e: reproduced the issue's exact scenarios — umbel list no longer crashes; control list-form extends: [good] renders correctly.