feat(footnotes): add back-to-reference link for footnotes (#2699)

[arshinsikka]

What is the purpose of this pull request?

• [x] Documentation update
• [ ] Bug fix
• [x] Feature addition or enhancement
• [ ] Code maintenance
• [ ] DevOps
• [ ] Improve developer experience
• [ ] Others, please explain:

Overview of changes:

• Re-enable the “↩” back-to-reference link in footnote definitions by returning the anchor in render_footnote_anchor
• Update the User Guide to document the footnote back link under the “Footnotes” section
• Add a manual functional test in test_site/index.md to verify that each footnote shows a ↩ link and that clicking it scrolls back to the original marker

Anything you'd like to highlight/discuss:

• We’ve updated both code and docs so users know the feature exists
• The manual test is added to the CLI test site; no automated unit tests exist for footnote rendering today
• Let me know if you’d prefer an automated snapshot test instead

Testing instructions:

1. Rebuild web assets: npm run build:web

2. Serve the test site: npx markbind serve packages/cli/test/functional/test_site

3. In your browser, navigate to Footnotes examples near the bottom of the page.

4. Confirm that each footnote item now has a ↩ link.

5. Click the ↩ link and verify it scrolls you back to the original superscript reference.

Proposed commit message: (wrap lines at 72 characters)

feat(footnotes): add back-to-reference link for footnotes (#2699)

Re-enables the “↩” link on footnotes so readers can return to the original reference. Updates User Guide and adds a manual test case to verify back-link rendering and behavior.

---

Checklist: :ballot_box_with_check:

• [x] Updated the documentation for feature additions and enhancements
• [x] Added tests for bug fixes or features
• [x] Linked all related issues
• [x] No unrelated changes

---

Reviewer checklist:

Indicate the SEMVER impact of the PR:

• [ ] Major (when you make incompatible API changes)
• [x] Minor (when you add functionality in a backward compatible manner)
• [ ] Patch (when you make backward compatible bug fixes)

At the end of the review, please label the PR with the appropriate label: r.Major, r.Minor, r.Patch.

Breaking change release note preparation (if applicable):

• To be included in the release note for any feature that is made obsolete/breaking

Give a brief explanation note about:

• what was the old feature that was made obsolete
• any replacement feature (if any), and
• how the author should modify his website to migrate from the old feature to the replacement feature (if possible).