fix(harmonia): print data in the chosen print language, not the UI locale (#6945)

[NicoleNG18]

Problem

Fixes #6945.

Printing a document (or a record from the manage form) in a language different from the current UI language produced a PDF whose labels were in the chosen print language but whose nomenclature values (Payment Method, Sent Method, Status, ...) were in the UI locale. The two halves of the document disagreed — e.g. a Bulgarian Sales Invoice template (ФАКТУРА, ПАДЕЖ) still reading "E-mail" / "Bank transfer" / "SENT".

Root cause

The Harmonia Print flow has two language selectors that were not kept in sync:

1. Template (labels) — the chosen print lang is passed as POST /services/print/{entity}?lang=bg, which selects the CMS template folder Templates/<Entity>/Print/bg/. ✅
2. Data (nomenclature values) — the {document, items} payload is fetched from the generated …PrintFeeder/{id} endpoint first. The feeder loads each related nomenclature through its generated repository, which overlays translations via Translator using User.getLanguage() → the request's Accept-Language header.

The feeder is fetched through the shared App.services.api.get(...), which always sets Accept-Language to the UI locale store (codbex.harmonia.language), never the print-dialog lang. So the data translated to the UI language while the template was in the print language.

Fix

Pin the feeder GET's Accept-Language to the chosen print language, so the multilingual overlay resolves data in the same language as the template — using the mechanism the rest of the platform already uses.

• application-core services/api.js: request() honors an opt-in { language } per-call override; absent it, the Region & Language store applies exactly as before (backward compatible).
• document-page.js.template and form-page.js.template: the print feeder fetch passes { language: lang }.
• Refreshed the engine-document guide, which still described the pre-feeder "client supplies the data" design.

Scope / notes

• The interactive UI print dialog is what Harmonia document/form print: nomenclature values render in the UI locale, not the selected print language #6945 reports and what this fixes.
• The server-side mail path (attach: print/report in Send.java/Notification.java) calls the feeder in a background listener where there is no request-scoped Accept-Language; it selects the template language via an expression but the feeder data stays in the base language. That is the same bug class but a different (in-process, thread-local) fix and is intentionally out of scope here.

Verification

Manual (no JS test harness): generate an app with a multilingual nomenclature and a bg print template, keep UI = English, print → Bulgarian; the nomenclature values now render in Bulgarian ("Банков превод", "Изпратена"). English-UI/English-print is byte-identical to before.

Reminder: api.js is bundled into the fat jar — a locally running instance needs application-core + build/application repackaged and a restart to reflect the change; target apps need regeneration to pick up the template edits.

🤖 Generated with Claude Code