refactor: consolidate markdown/ADF conversion

[rianjs]

Summary

Consolidate markdown-to-ADF (Atlassian Document Format) conversion logic to eliminate duplication between tools.

Current State

Both tools have markdown-to-ADF conversion:

cfl (tools/cfl/pkg/md/):

• Full bidirectional conversion (markdown ↔ ADF)
• Macro support for Confluence-specific features
• Well-structured with separate files for each direction

jtk (tools/jtk/api/markdown.go):

• Markdown to ADF only (372 lines)
• Duplicates significant goldmark parsing logic
• Simpler implementation without macro support

Proposed Changes

1. Evaluate if jtk needs the full cfl implementation or a subset
2. Move shared ADF conversion logic to shared/adf/ package
3. cfl's more complete implementation should be the basis
4. jtk imports shared package, removing its local markdown.go

Considerations

• Jira descriptions don't need Confluence macros
• May want to keep cfl's macro handling separate
• Core ADF node types are shared between products

Impact

~300+ lines could be consolidated

Complexity

This is a larger refactoring effort - recommend tackling after simpler consolidations are complete.

[rianjs]

Analysis from Code Simplification Sprint

After completing simpler consolidations (#14-#22, #24-#25), I've analyzed this issue in detail.

Current State

jtk (tools/jtk/api/markdown.go - 372 lines):

• Single file with MarkdownToADF() returning *ADFDocument
• Uses goldmark with table and strikethrough extensions
• Supports: headings, paragraphs, code blocks, lists, blockquotes, tables, inline formatting
• Uses value types ([]ADFNode)

cfl (tools/cfl/pkg/md/to_adf.go - 459 lines + macro support):

• Returns JSON string via ToADF()
• Uses pointer types ([]*ADFNode)
• Has additional features: ordered list start positions, table cell colspan/rowspan
• Has separate macro handling layer

Key Differences

Feature	jtk	cfl
Return type	*ADFDocument	JSON string
Node types	Value ([]ADFNode)	Pointer ([]*ADFNode)
Ordered list start	No	Yes
Table cell attrs	No	colspan/rowspan
Hard/soft line breaks	Yes	No
Macro support	No	Yes (separate layer)

Recommendation

This consolidation is more complex than the other issues for several reasons:

1. Different APIs: One returns a struct, the other returns JSON
2. Type differences: Value vs pointer types requires careful migration
3. Feature differences: Each has features the other lacks
4. Macro layer: cfl's macro handling is Confluence-specific and should remain separate

Suggested approach (for future sprint):

1. Extract core ADF types to shared/adf/types.go
2. Create shared conversion functions for common elements
3. Keep tool-specific wrappers for different return types
4. Maintain cfl's macro layer as separate package

This would be ~300+ lines of consolidation but requires careful testing of both tools' markdown conversion paths.

Leaving open for a future focused effort.