fix(plugin-shiki): highlight lines not working with code block options (close #577)

[CuteReimu]

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Provide a description in this PR that addresses what the PR is solving. If this PR is going to solve an existing issue, please reference the issue (e.g. close #123).

What is the purpose of this pull request?

• Bug fix
• New feature
• Other

Description

Highlighted lines ({1,2}) fail when combined with other code block options like :no-collapsed-lines or :collapsed-lines=5. The regex in attrsToLines incorrectly captures hyphens from option names instead of line numbers. This bug occurs regardless of the order in which the syntax elements appear.

Examples that fail before this fix:

```java :no-collapsed-lines {1}
System.out.println("Hello World");
```

```java {1} :no-collapsed-lines
System.out.println("Hello World");
```

Root cause:

The bug occurs due to how the code processes markdown code fence syntax through two stages:

1. Preprocessing by highlightLinePlugin (in highlightLinesPlugin.ts):

   • Markdown input: java {1} :no-collapsed-lines
   • Line 29: Removes {1} pattern → "java :no-collapsed-lines" (note: double space where {1} was)
   • Line 34: Extracts line numbers from {1} → "1"
   • Line 45: Appends line numbers to end → "java :no-collapsed-lines 1"
   • This preprocessed string is then passed to attrsToLines

2. Regex matching in attrsToLines (in utils.ts):

   • Original regex: /^(?:\[.*?\])?.*?([\d,-]+).*/
   • The non-greedy quantifier .*? matches as few characters as possible before finding [\d,-]+
   • In the preprocessed string "java :no-collapsed-lines 1":
     • .*? matches "java :no" (minimal match, stops as soon as possible)
     • [\d,-]+ then finds the first matching character: the - in :no-collapsed-lines at position 9
     • Since the next character 'c' doesn't match [\d,-], it captures just "-" and stops
     • The regex never reaches the "1" at the end because it already found a match earlier

This happens in both orderings:

• java :no-collapsed-lines {1} → preprocessed to "java :no-collapsed-lines 1" → regex captures -
• java {1} :no-collapsed-lines → preprocessed to "java :no-collapsed-lines 1" → regex captures -

Why the non-greedy .*? causes the problem:
The non-greedy quantifier makes the regex stop at the FIRST character matching [\d,-]+, not look for the best or last match. Since - appears before 1 in the string (within :no-collapsed-lines), it gets captured instead of the intended line number 1 at the end.

Fix:
Changed regex to /\s+([\d,-]+)\s*$/ — anchors to the end of string and matches line numbers after the final space, correctly extracting them regardless of option ordering.

Changes:

• Updated attrsToLines() regex in src/node/utils.ts
• Added test coverage for combined options scenario (both orderings)

Screenshots

N/A - No UI changes