fix: prevent markdown converter hang and support label custom fields

[Hinne1]

Summary

Two independent bug fixes discovered while creating NX-15439 — both surfaced from the same incident response session.

1. Markdown converter could hang indefinitely

atl issue create --description '...' could silently spin forever on certain indented markdown — most reliably an indented fenced code block inside an ordered list:

1. Verify the token works:
    \`\`\`
    curl https://api.example.com/v1/me
    \`\`\`

Root cause: parseBlocks checked strings.HasPrefix(line, "\u0060\u0060\u0060") against the raw line, so the leading whitespace caused indented fences to slip past every block branch and fall into parseParagraph. parseParagraph then broke immediately on the trimmed prefix and returned consumed=0. The dispatch loop did i += 0 and re-dispatched the same line forever. No timeout, no error.

Fix:

• parseBlocks trims before checking the \``` prefix so indented fences are parsed as code blocks.
• parseParagraph is now defensive: it only treats block-prefix lines as a break condition after at least one paragraph line has been collected. A guarantee that consumed >= 1, so any future dispatcher gap can no longer cause an infinite loop.

2. Label-typed custom fields rejected by --field

Custom fields with type labels (e.g. NX Repo, Application — schema.custom = "...customfieldtypes:labels", type = "array", items = "string") returned 400 because the CLI sent the bare string instead of an array:

$ atl issue edit NX-15439 --field "Repo=API"
Error: 400 Bad Request: customfield_10410: Specify the value for Repo in an array of strings

The previous code only handled labels when Schema.Custom == "" (the system Labels field), missing every custom-label field. The workaround was building a JSON file and using --field-file for what should be a single-value flag.

Fix:

• Added Items to FieldSchema so the parser can read the schema's element type.
• coerceFieldValue now detects label-typed fields three ways: Schema.Custom contains "labels", OR Type=="array" && Items=="string", OR Type=="array" && Custom=="" (preserved behavior). All coerce to []string.

After this:

atl issue edit NX-15439 --field "Repo=API" --field "Application=MTS"

works without --field-file.

Test plan

• TestMarkdownToADF_IndentedCodeFenceInList — repros the original hang, guarded by 2s timeout
• TestMarkdownToADF_IndentedCodeFenceTopLevel — top-level indented fence
• TestParseParagraph_NeverReturnsZero — table-driven check for every block-prefix edge case (#, \``, >, -, 1., ---`)
• TestCoerceFieldValue_LabelsCustomField — repros the field 400 error, single + comma-separated
• TestCoerceFieldValue_StandardLabelsField — preserves system Labels behavior
• TestCoerceFieldValue_SelectStillWorks / _RadioStillWorks — regression guards
• go test ./... — full suite passes
• make lint — zero issues
• End-to-end verified against prod Jira: built from this branch and successfully created NX-15441 with the original hang-triggering markdown AND --field "Repo=API" --field "Application=MTS" in a single command (NX-15441 then closed).

[gemini-code-assist]

Code Review

This pull request addresses an infinite loop in the markdown parser triggered by indented code fences and extends Jira field coercion to support custom label fields. The markdown parsing logic now correctly handles indented fences by trimming whitespace and guarantees that parseParagraph always consumes at least one line to prevent hangs. In the Jira field utility, the logic for identifying label-type fields was expanded to include custom fields. Feedback was provided regarding the need to filter out empty strings when parsing comma-separated labels to avoid potential API rejection.