Closes #5488

Problem

Every reference to a given note was rendered with the same id:

a<sup class="footnote-ref"><a href="#fn-1" id="fnref-1">1</a></sup>
 b<sup class="footnote-ref"><a href="#fn-1" id="fnref-1">1</a></sup>.

id must be unique in a document, and the consequence is not only formal: the note carried a single ↩ pointing at fnref-1, so the second and later references were unreachable — the arrow always landed on the first one.

Fix

Number the occurrences. The first reference keeps fnref-N; later ones take a -k suffix, and the note gets one arrow per reference — bare for the first, numbered after that, so they can be told apart:

a<sup class="footnote-ref"><a href="#fn-1" id="fnref-1">1</a></sup>
 b<sup class="footnote-ref"><a href="#fn-1" id="fnref-1-2">1</a></sup>.

<li id="fn-1"><p>shared
  <a href="#fnref-1" class="footnote-backref">↩</a>
  <a href="#fnref-1-2" class="footnote-backref">↩2</a></p></li>

This is the shape GFM emits. pandoc takes the other route and duplicates the note itself (two entries numbered 1 and 2), which loses the "one note, cited twice" relationship — muya's reuse is the better behaviour, so only the id allocation and the backref set change here.

A note referenced once is untouched: same single fnref-N, same bare ↩.

Out of scope

The editor's inline renderer still puts id="noteref-{identifier}" on every reference (packages/muya/src/inlineRenderer/renderer/footnoteIdentifier.ts), so the same duplication exists in the contenteditable DOM. Fixing that needs document-wide occurrence numbering, which the per-block inline renderer has no access to, and the current behaviour there is benign — Footnote's backlink calls getElementById, which lands on the first reference. Noted in #5488 rather than bundled here.

Tests

New in packages/muya/src/state/__tests__/footnoteHtml.spec.ts:

• three references to one note produce fnref-1, fnref-1-2, fnref-1-3, and three backref arrows labelled ↩, ↩2, ↩3, each pointing at its own reference
• a note referenced once still gets exactly one bare ↩

The first fails on develop; the second passes either way and pins the common case against the change.

Verification

muya unit suite 1987 ✅, CommonMark/GFM conformance 1347 ✅, eslint + tsc ✅, desktop unit suite 861 ✅, desktop build ✅.