fix(ExportHtml): don't poison ol counter when closing a sibling ul (#7791)

When an ordered-list level was the only consumer of olItemCounts,
closing any list at that depth (including an unordered list that
happens to share the level) reset olItemCounts[level] to 0. A later,
unrelated ordered list at the same depth then took the
"counter exists but is 0" branch in the ol-opening logic and emitted
`<ol class="...">` without the start attribute that line.start would
have supplied.

Round-trip: importing
  <ul>...<ul>...</ul></ul><ol><li>x<ol><li>y</li></ol></li></ol>
exported the inner ol as `<ol class="number">` instead of
`<ol start="2" class="number">`, because the closing of the inner
bullet ul wrote olItemCounts[2]=0 before the outer ol even opened.

Gate the reset on line.listTypeName === 'number' so closing an
unordered list never touches the ol bookkeeping. Closing an actual
ordered list still resets, as #7470 intended.

Fixes #7786
Fixes #7787

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: JohnMcLear

src/node/utils/ExportHtml.ts

@@ -470,7 +470,10 @@ const getHTMLFromAtext = async (pad:PadType, atext: AText, authorColors?: string
           // preserve counters so numbering can continue after interruptions.
           // Use 0 as sentinel (not delete) so the ol-opening logic knows this
           // level was explicitly reset and won't fall back to line.start.
-          if (diff + 1 > actualNextLevel) {
+          // Only reset when closing an ordered list — closing an unordered list
+          // at the same level must not poison the ol counter for a future
+          // unrelated ol at this level (which would still want line.start).
+          if (line.listTypeName === 'number' && diff + 1 > actualNextLevel) {
             olItemCounts[diff + 1] = 0;
           }