Closes #13074

Problem

The help/FAQ pages (e.g. /help/faq/editing) render literal <br /> as visible text. The root cause is that Open Library has two markdown engines that disagree on hard breaks:

When editor-saved content is displayed, OLMarkdown appends its <br/> right after the editor's trailing \. The backslash escapes the <, so the tag renders as the literal text <br />. Verified against the real renderer:

editor saves:  'first line\\\nsecond line'
OLMarkdown  →  'first line&lt;br /&gt;\n   second line'   # literal <br /> shown to the reader

This affects every multi-line paragraph edited via the WYSIWYG editor, not just the orphaned footnote block on that FAQ page (the page history's "stray forward slashes removal" edit is the same backslashes).

Steps to reproduce

Via the WYSIWYG editor (the real-world path — any page that mounts <ol-markdown-editor>: a /type/page wiki/help page, or a work description):

1. Open the editor and type a line, press Shift+Enter (a hard break — plain Enter makes a new paragraph, which is fine), type a second line.
2. Save, then view the rendered page → the line break shows as the literal text <br />.
   • Opening an existing multi-line page in the editor and simply re-saving also reproduces it: with breaks: true, markdown-it turns every existing single-newline line break into a hard-break node, so a plain open→save corrupts the whole page at once.

Renderer only (no editor needed) — save page source with a line ending in a single backslash:

first line\
second line

→ view it and the literal <br /> appears.

Fix (editor + renderer)

• Editor — new OLHardBreak node (openlibrary/components/lit/hard-break.js, wired into editor-core.js) serializes hard breaks as a bare newline (OLMarkdown's dialect) instead of CommonMark \. Re-saving a page through the editor now also cleans up legacy backslash/<br> cruft.
• Renderer — LineBreaksPreprocessor (olmarkdown.py) normalizes away a lone trailing CommonMark hard-break \, so already-corrupted pages display correctly without needing a re-save (no leaked <br />, no stray \). It also no longer glues a <br/> onto the line directly above a link-reference definition.
• Added @tiptap/extension-hard-break as an explicit dependency (was a transitive/phantom dep via starter-kit).

Tests

• JS round-trip tests (tests/unit/js/OLMarkdownEditor.test.js): hard breaks serialize without backslashes/<br>.
• Python render tests (openlibrary/tests/core/test_olmarkdown.py): the hard-break and reference-block cases.
• Both new test sets were confirmed to fail without the fix (see the verification comment for before/after rendered output and red/green results).

Notes

• The orphaned footnote block on the FAQ page is still worth deleting from the wiki source; this change makes the renderer degrade gracefully instead of emitting literal markup.
• Longer term, converging on a single markdown engine (e.g. markdown-it-py server-side, to match the editor) would remove the dialect mismatch entirely — worth a separate issue.

Testing

• npm run test:js — 88 passed (OLMarkdownEditor suite)
• pytest openlibrary/tests/core/test_olmarkdown.py — 5 passed
• pre-commit (ruff / mypy / eslint / POT) clean
• Manual before/after on a local dev instance (literal <br /> → clean line breaks)