fix(intent): server-side PDF renders resolve nomenclature values in the render language (#6947)

[NicoleNG18]

Problem

Fixes #6947.

The two server-side PDF render paths - the immutable snapshot copy minted when a document is issued, and the notify attach: print / recordPrint / report PDF mailed to the recipient - render the .print template in the document's (mint) language but resolve the data values (Payment Method, Sent Method, Status, and any multilingual nomenclature) in the default language. For any document whose language is not the default, the archived copy and the emailed PDF come out with, e.g., Bulgarian labels but English values (ФАКТУРА … Bank transfer / ISSUED).

This is the same class of defect as the client-side print-language bug (#6945, fixed in #6946), but on a different code path. #6946 is explicitly scoped to the interactive UI dialog and calls this case out as "a different (in-process, thread-local) fix" - which is this PR.

Root cause

Both paths already compute a render language (language: / languageFrom:, falling back to sdk.print.Print.defaultLanguage()) and pass it to Print.render(entity, language, payload), so the template is selected from the right CMS language folder. But the payload is built by calling the generated <Master>PrintFeeder().feed(id) (or, for attach: report, the report repository) in-process. The multilingual overlay a generated repository applies reads sdk.security.User.getLanguage() → the request's Accept-Language header. A BPM service task has no request, so getLanguage() returns null, Translator no-ops, and the values fall back to the base/default language while the template is in the mint language.

Fix

A thread-bound language override that getLanguage() prefers over the (absent) request header - the mechanism the platform lacked for off-request renders. Each server-side render sets it to the language it already computed, around the feed/render, and clears it in a finally so a pooled BPM worker thread never leaks it. The feeder's HTTP @Get("/{id}") contract is untouched (the browser still carries Accept-Language), and every read still goes through the generated repositories (validations / events preserved).

• components/api/api-security UserFacade: setLanguage(String) / clearLanguage() + an override branch at the top of getLanguage().
• components/api/api-modules-java sdk.security.User: expose setLanguage / clearLanguage for the generated (client-Java) delegates.
• template-application-events-java: Snapshot.java.template, Send.java.template and Notification.java.template wrap the feed/render in User.setLanguage(language) … finally { User.clearLanguage(); } - for every attach branch (print, recordPrint, report), and for report the override also covers the report findAll whose :language binding reads getLanguage().
• engine-intent/CLAUDE.md: mint-language bullet updated (the mint language now names the template AND the data).

Scope / notes

• attach: report (intent: notify can attach a parameterized REPORT render (attach: { report, bind }) - the customer-statement mail #6931) shares the exact root cause and is fixed by the same change.
• Purely additive to UserFacade / User; no behaviour change on the HTTP path. The override is always cleared in finally; these delegates never nest, so worker threads never leak a language.

Verification

• UserFacadeLanguageOverrideTest (new, api-security): the override wins over the absent request language, clearLanguage() restores the unresolved state, null/blank leaves it unset. Passing locally (4/4).
• IntentEmissionCoverageIT: each attach branch (SendBillTransition = attach: print, BillFlowMailBillSend = attach: report, BillFlowShareBillSend = attach: recordPrint) now asserts the generated delegate emits the User.setLanguage(language) / clearLanguage() wrapper around its render - and the IT's client-Java compile proves the emitted code compiles. IntentEngineIT's OrderCopy snapshot compiles the Snapshot template.
• mvn formatter:validate and the release-profile javadoc build pass on the changed modules.

Reminder: the events templates are bundled into the fat jar - a locally running instance needs template-application-events-java + build/application repackaged and a restart, and target apps need regeneration, to reflect the change.

🤖 Generated with Claude Code