Add frontend UX for Celery-based machine translation progress

[hannaseithe]

Short description

Adds the frontend UX for the Celery-based machine translation flow introduced in #: a lock dialog for the editor whose language is being translated, a non-blocking progress/outcome banner for source-page editors, and progress indicators in the page tree list view. More UI features will follow in later PRs.

Proposed changes

• Extend the edit-mode heartbeat (content-edit-lock.ts) to read the new MT status from the heartbeat response and act on it: while the language currently open for editing is itself being machine-translated, show a lock dialog and block editing; once it finishes, reload the page automatically.
• Add _machine_translation_lock_dialog.html: no heading, a spinner, and a "wait a moment or leave this page" link back to the list view, per the UXer's spec.
• For source-page editors (editing the language MT is being triggered from, not the target), show a non-blocking in-progress banner and, once finished, the outcome report — instead of locking the page. This piggy-backs on the same heartbeat poll rather than adding a second polling loop, since the heartbeat already fires every few seconds and duplicating that felt wasteful and easy to drift out of sync.
• Extract the report-banner rendering logic shared between this new source-editor case and the existing list-view poller into mt-report-banner.ts (showBanner/showReportBanners), and update mt-progress-poll.ts to import from it instead of duplicating the same logic.
• Add progress indicators to the page tree list view (pages_page_tree.html/pages_page_tree_node.html): a spinner with a "currently being machine translated" title for languages mid-translation, and a "machine translation finished - click to refresh" hint once done — driven by the mt_task_ids context data added in the backend PR.
• Give the new lock dialog its own z-index (#machine-translation-lock-dialog, 3095) between the popup overlay (3090) and the human-lock takeover dialog (3100), so the dialog renders above the overlay but the (more urgent) human-lock takeover always wins if both would ever show at once.
• Refactor messages.html to use new .banner-info/.banner-success/.banner-warning/.banner-error CSS classes instead of inline Tailwind utility strings, reused by the new banners so all of this project's status banners look consistent.
• Add German translations for all new UI strings.

Side effects

• Editing is now actively blocked (via the dialog) while the currently-open language is being machine-translated — previously nothing blocked editing during MT at all, since it ran synchronously and had already finished by the time the editor was even usable. This is an intentional, new restriction per the design, not a bug, but worth calling out explicitly as a behavior change.
• messages.html is a widely shared template (used for every Django message banner across the app, not just MT ones) — refactoring it to .banner-* classes should be visually identical to before, but it's worth a broad visual smoke-check rather than assuming it's scoped to MT.
• The heartbeat request now does more work per call (also computing MT status), and its JSON payload is slightly larger, since this was deliberately consolidated into the existing poll instead of adding a second one.
• This PR is meaningless without the backend PR merged/present first — the list-view indicators and heartbeat status entirely depend on data the backend PR adds (mt_task_ids, the heartbeat's MT status fields).
• No new automated frontend/JS tests were added for this PR — consistent with this project's existing convention of not writing JS/vitest tests, but flagging explicitly since this PR is almost entirely frontend code.

Faithfulness to issue description and design

There are no intended deviations from the issue and design.

How to test

Needs the backend PR's branch merged in (base branch for this PR) - no other special setup.

• Open a page for editing, trigger MT into the language currently open (e.g. from another tab/session, or by editing a different language and triggering translation into this one), and confirm: the lock dialog
  appears with a spinner, editing is blocked, and the page reloads automatically once translation finishes.
• Trigger MT from a page's source language and confirm: no lock dialog appears there, a non-blocking "currently being translated" banner shows instead, and once finished, the outcome report (success/partial-success wording) appears.
• Open the page tree list view while a translation is in progress for one of its languages and confirm the spinner/title shows on the right rows, and that it changes to the "click to refresh" hint once finished.
• Check that the new dialog renders above the popup overlay, and that the human-lock takeover dialog still takes visual priority if both would apply at once.
• Manually verify the German translations read naturally in context (dialog, banners, list view).

Resolved issues

Relates to: #4393
Fixes: #4510

---

Pull Request Review Guidelines