fix(footnote): position the preview popup from the current footnote's height

[xiaolai]

Summary

The footnote preview popup sits above its reference, so its position depends on its own height. The WYSIWYG popup measured itself before resizing its textarea for the footnote being shown, so it reused the previous footnote's height. Hovering footnote ① and then ② put ② at ①'s offset; hovering ② again was correct, because the leftover height was by then its own. That matches every step in #1494.

Source mode had a worse version of the same bug: the base view never re-showed a popup that was already open, so hovering straight from one footnote to another kept the old text at the old place. It also always positioned as if 100px tall.

Policy Gates (Required)

• This PR is single-focus (one issue, one problem, one objective).
• This PR includes 100% test coverage for changed behavior and changed code paths.
• If this is a bug fix, the linked issue contains detailed reproduction context.

Linked Issue

• Fixes [Bug] 引用预览区的相对高度计算有延迟和错误缓存 #1494

Type of Change

• Bug fix
• Feature
• Docs
• Refactor
• Test-only
• Other

What Changed

• WYSIWYG (FootnotePopupView): size the textarea before measuring and positioning; re-position on input as the popup grows.
• Source footnote (SourceFootnotePopupView): override SourcePopupView.shouldReshow (now on main) to re-show when the hovered footnote changes; position from the rendered height after the content is set; re-position on input.
• Both modes: re-anchor when the hover moves to another reference of the same footnote (same label, different referencePos; only openPopup writes that field, so this cannot fire spuriously).
• Docs: website/guide/popups.md (all locales) now lists the Source-mode trigger for footnote popups.

Known limit: in Source mode, moving from a footnote's definition to its reference doesn't re-anchor, because both carry the same label and referencePos. Re-showing on every anchor change would instead reset unsaved edits when the same footnote is clicked again.

Validation

• I ran pnpm check:all locally.
• I added or updated tests to fully cover behavior changes.
• I manually verified critical flows.

Two new *.position.test.ts files (11 tests) were written first and seen failing, including the reporter's exact sequence and the Source-mode stale-text case. jsdom has no layout, so the tests simulate one in which the textarea's scrollHeight follows its text and the container's height follows the textarea.

Not verified in the running app. Manual check: hover a long footnote, then move straight to a short one — the gap above the reference should stay constant, in both WYSIWYG and Source mode.

UI Evidence (if applicable)

None yet — see the manual check above.

PR Checklist

• The PR avoids unrelated refactors or cleanup.
• The issue context is clear (linked issue or explanation above).
• Docs/changelog were updated if behavior or usage changed.
• I am ready to address review feedback.

[xiaolai]

The red frontend check comes only from the fe-static security-audit step: a new, unfixed braces advisory (GHSA-vfj7-8cjw-p6xm) that fails every PR, main included. Unblocked by #1496; I'll update this branch from main once #1496 merges.