Follow-up: tighten G2 list-item attribute edge cases (sequential {...} and nested inner-item)

[dereuromark]

Two narrow edge cases surfaced during code-quality review of #186 (G2 list-item terminator fix). Both are improvements over the pre-#186 master behavior but worth tightening.

1. Sequential {...} lines drop all attributes silently

Input:

- item
  {.x}
  {.y}

Current (post-#186) output:

<ul><li>item</li></ul>

Both .x and .y vanish. Pre-#186 master at least kept .x on <li> (with a stray empty <p></p> for .y). Now both are silently swallowed.

Mechanism: the peek-ahead in src/Parser/BlockParser.php sees {.y} as "more item content," pushes {.x} back into $itemLines, then the continuation loop gobbles {.y} as continuation. When parseBlocks runs on {.x}\n{.y} with no follow-up block, both end up in pendingAttributes and are discarded when the item ends.

Proposed fix: when the peeked line is itself another {...} attribute pattern, treat both as additional item attributes to merge onto the <li> rather than pushing the first back as a block-attr that has no following block.

Three-attr case {.a}\n {.b}\n {.c}\n has the same behavior.

2. Nested-list inner-item {...} continuation still partial

Input:

- outer
  - inner
    {.x}
    > q

Current output:

<ul><li>outer
- inner
<p>
&gt; q</p>
</li></ul>

- inner is consumed as plain text (pre-existing tight-list nesting quirk needing a blank line) and > q becomes a literal paragraph instead of a <blockquote>.

This is improved over pre-#186 master (where > q escaped outside the entire <ul> as a sibling paragraph). But it's not yet the natural "blockquote inside the inner <li>" outcome a reader would expect. Probably needs nested-list tight-marker handling rather than further attribute-line changes.

Suggested action: either fix the nested-list tight handling or add a @todo comment near the G2 fix site noting this is a known partial case.

---

Both are narrow corner cases — won't affect typical attribute usage and the suite stays green — but worth a follow-up PR.

Source: code-quality review of #186, Important findings #1 and #2.