Migrate content_kinds.py to spec + code generation #184

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Overview

content_kinds should be generated from a spec in the format #182 introduces, including its file-format-to-kind MAPPING. Its public Python API should not change.

Complexity: Medium
Target branch: main

Context

• kindlookup.json holds only kind names; the 11-entry MAPPING is hand-written in content_kinds.py against file_formats constants.

The Change

• The spec should record which file formats belong to each kind, so MAPPING is no longer hand-written.
• js/ContentKinds.js should export the constants as its default export and MAPPING as a named export.

Acceptance Criteria

• le_utils/constants/content_kinds.py and js/ContentKinds.js are generated from spec/constants-content_kinds.json, kindlookup.json is deleted, and make build on a clean checkout leaves no diff.
• The pinned-API test from Add namedtuple spec support and migrate file_formats.py #182 passes unchanged for content_kinds.

AI usage

I made the decisions recorded on #181 and #182; Claude Code applied them to this module against the current code and drafted the issue.