TEDEFO-5133: Select preferred language only when translating view templates

[rousso]

Problem

EFX-1 wrapped every read of a text-multilingual field value in efx:preferred-language-text(...), regardless of what was being translated. That function is defined only in the notice viewer's XSL, so any Schematron rule or standalone expression that read a multilingual value produced output that cannot execute.

Nothing warns the author. BT-500-Organization-Company is not present is fine, while is empty on the same field silently emits the broken call — the two are one word apart.

No shipped SDK artefact is affected today: all 38 rule conditions in fields.json that reference multilingual fields use presence tests, which never read a value.

Change

The preferred language is now selected only when translating view templates.

• XPathScriptGeneratorV1 no longer overrides composeFieldValueReference. The @languageID guard moved to an override of getTextInPreferredLanguage, keeping the XPath-specific logic in the XPath generator.
• EfxTemplateTranslatorV1 gained a private composeFieldValueReference(PathExpression) — the single place where multilingual fields are handled — used by the $value shorthand, the #{...} label shorthand and the two field reference overrides.
• exitScalarFromFieldReference and exitSequenceFromFieldReference check stack.peekType() and delegate straight to the parent unless the field is multilingual, so attribute handling stays where it was.

EfxExpressionTranslatorV1 is unmodified. No interface changes. V2 is untouched.

Tests

The three template characterisation tests were written and run against unmodified code before any production change, and pass unchanged afterwards. A fourth, covering a multilingual field used as a sequence, was added later and verified the same way against origin/develop.

The V1 expression tests that asserted the wrapper now assert its absence, and a sequence case was added.

EfxTestsBase no longer registers the efx: extension functions with Saxon. With the namespace declared but nothing registered, an expression that calls one fails to compile, so assertValidXPath() now enforces the boundary on its own.

Full suite: 1340 tests, 0 failures.