feat(tests): validate the catalog corpus against musher-dev/spec

[amiralis1365]

The seed commit left this repository deliberately unvalidated — the platform
was the sole validator, and no CI ran here. The platform is still the sole
authority, but "the platform will reject it" is a slow way to learn that
an item is malformed. This adds the same contracts, applied early.

Not a second authority

Schemas are fetched at run time from the tip of the public
musher-dev/spec, never vendored. A copy
held here would be a second answer to "what is the contract" — and a stale copy
is worse than none, because it passes a corpus the live spec would reject,
silently. Nothing about the source is configurable, and if the fetch fails the
suite fails loudly, naming the URL. The repo is public, so no credential is
read anywhere in the suite.

What runs

File	Phase	Checks
spec.test.ts	—	Bundles resolve and are self-contained. Fails first, so the corpus is never judged against a 404 page.
parser.test.ts	parser	The Musher YAML profile (§7.1) — one doc per file, string keys, no anchors/aliases/merge keys/tags, size and depth bounds.
structural.test.ts	structural	Each document against its family's fetched JSON Schema.
semantic.test.ts	semantic	Cross-document rules — identity, reference resolution, path containment, media, description Markdown, image pinning, endpoint resolution, connection compatibility, parameter coverage.
layout.test.ts	—	Item folder structure.
rules.test.ts	—	The rules themselves, against deliberately broken synthetic items.

capability is deliberately absent. Whether a Compute Profile is offered,
whether a published component exists, whether a version is monotonic — all
decided against the platform catalog over the network, and an implementation
MUST NOT report a rule it cannot check. An item green here can still be
rejected at sync.

rules.test.ts guards the guards: a suite that passes on a clean corpus passes
just as readily when a rule is silently unreachable, so each case breaks one
thing and asserts the normative diagnostic fires.

Also included

• CI — validate on push/PR plus a daily schedule (the part that only makes
  sense because schemas aren't vendored: it catches a spec change that stops
  accepting an item, in the window before the next catalog PR). devcontainer
  is path-filtered and stays quiet on items-only changes.
• Dev container, Taskfile, lefthook — the same checks locally. Taskfile
  wraps the npm scripts, so npm test still works in a bare checkout. Hook
  split is about the network: npm test fetches, so it's pre-push, not
  pre-commit — a commit made offline shouldn't fail for an unrelated reason.

Two README corrections the suite forced into the open

• Blueprint component references are repo-local paths that must begin ./ and
  end .yaml, not bare stems. The prefix is load-bearing — a bare name isn't
  distinguishable from the UUID a published reference uses. The old example
  (component: my-app) is rejected by the structural phase.
• A connection's two ends must agree on schema.type, and on semanticType
  wherever the consuming input names one.

Test plan

task check — the full CI set — passes locally:

• npm run typecheck — clean
• npm test — 377 tests, 377 pass, 0 fail across all 13 items
• shellcheck (-S style) — clean
• actionlint — clean

No item YAML or media is touched; this is additive plus the README.

🤖 Generated with Claude Code