fix(lore): validate --kind before import (fixes #87)

[CatfishGG]

Summary

lore catalog DIR --kind <kind> accepted any string for --kind and silently stored it in the corpus, corrupting downstream filtering and search.

This PR validates --kind against the known taxonomy (idea, research, decision, observation, principle) before import and returns a descriptive error listing valid options if the value is unknown.

Changes

• internal/lore/catalog.go: Added validation in Catalog() — rejects unknown kinds with a clear error message
• internal/lore/catalog_cmd.go: Added validation in the CLI handler — same check before calling Catalog()
• internal/lore/catalog_test.go: Added TestCatalog_InvalidKind covering the error case

Acceptance criteria (from #87)

• Catalog rejects unknown --kind values up-front
• Error message lists valid options
• Default (no override) behavior unchanged — AllKinds() returned nil for empty input is still respected

Closes #87

[kunallanjewar]

Closing in favor of #97, which landed as the fix for #87. Both PRs solved the right bug with the right test shape — the call came down to which one matched the existing kind-validation pattern in the lore package. #97 reuses the ErrInvalidKind sentinel and isValidKind helper that Inscribe (inscribe.go:116) and Update (update.go:129) already use, so all three write-paths now share one validator and callers can errors.Is against ErrInvalidKind uniformly.

Genuinely appreciate the work here — your test (verifying the error mentions every valid kind) was a thoughtful angle, and the dual-layer validation idea is defensible in cases where the CLI handler does pre-DB work that the lib can't see. In this codebase the handler just forwards inputs to Catalog(), so the lib check ended up being the right single gate. Hope you'll send more patches; the catalog/lore area still has open issues.