feat(monday-import): sub-issue relationships and custom Linear statuses

[shannonwho]

Summary

Adds two capabilities to the Monday importer, each tied to a use case the prior flow couldn't represent:

• Use case 1 — parent/sub-issue relationships per item. Subitems are now imported as real Linear sub-issues (linked via parentId) when items are imported in parentIssue mode or in issue mode with subitems.enabled. A new fieldMappings.subitem block lets sub-issues carry their own field/status mapping distinct from their parents. Previously subitems were either ignored or flattened.
• Use case 2 — issue/project statuses beyond what exists in Linear. Configs can declare customIssueStates and customProjectStatuses (name + Linear state type + optional color). Before import, the client ensures each declared status exists in the target team/workspace, creating it if missing, so Monday workflows with bespoke statuses import cleanly instead of falling back to _default.

Changes

• src/config/schema.ts — new customIssueStates, customProjectStatuses, and fieldMappings.subitem types.
• src/linear/client.ts — ensureCustomIssueStates / ensureCustomProjectStatuses create-if-missing logic.
• src/importer/monday-engine.ts — sub-issue creation via parentId; subitem-specific field/status mapping.
• src/commands/run.ts — wires status provisioning into the run pipeline; clearer parent/sub-issue logging.
• src/commands/init.ts, README.md — config scaffolding and docs for the new options.

Test plan

• Dry-run a Monday export with subitems in issue mode + subitems.enabled — verify sub-issues print under their parents.
• Live import the same export — verify sub-issues appear under their parent in Linear with the correct parentId.
• Run with customIssueStates containing a status not present in the target team — verify it's created and items map onto it.
• Run with customProjectStatuses containing a new workspace status — verify it's created and projects map onto it.
• Re-run the same import — verify status creation is idempotent (no duplicates).

🤖 Generated with Claude Code

[linear-code]

Left some comments. The core logic is solid, but sub-issue creation failures are silently dropped from the import result, meaning result.success reports true and result.failures stays empty even when sub-issues fail to create in the new isParentIssue path.

[linear-code]

Sub-issue creation failures not tracked in result.failures or result.success

(High) When a sub-issue fails to create in the isParentIssue path, the catch block only logs to console and does not call result.failures.push(...) or increment result.summary.failed. This means result.success = result.failures.length === 0 (evaluated at line ~234) returns true even when sub-issues were silently dropped. Callers that check result.success or result.failures to decide whether to re-run or alert on failures will see a false all-green. The same gap exists in the pre-existing isProject subitem path, but the isParentIssue sub-issue loop is entirely new to this PR and should track failures consistently with the outer item loop.