fix(pdf): respect export-request language over DB template language

[Ar1anit]

Fixes #536.

Problem

For Harvard Classic (and latently for the other two registered designs), selecting German in the application edit flow renders correctly in the in-app preview but the exported PDF comes out with English section headings (Education, Skills, Professional Experience) while the body text (LLM-generated bullets, summary, cover letter prose) is in German.

Root cause

The preview renders client-side via a frontend component that takes the user-chosen language directly as a prop.

The export, however, renders server-side via ReactPdfRendererService, which constructs meta.language from the resolved DB template row's language column. The three registered templates picked their localized section headings with:

const lang = meta.language || data.language || 'en';

seed-multilingual-templates.ts only seeds one variant per design (English), so application.processor.ts → resolveTemplateForLanguage('<category>', 'de', …) doesn't find a German variant and falls back to the English row (with a warning log). meta.language is then 'en', the precedence above picks 'en', and the localized headings render in English — even though data.language was set to 'de' from the export request and the LLM body is already in German.

Fix

Flip the precedence in all three resume templates so the explicit export-request language wins over the DB row's static language column:

const lang = data.language || meta.language || 'en';

This makes export-time language correctness independent of which language variants happen to be seeded — a one-line change in each of:

• apps/api/src/pdf-v2/templates/harvard-classic.tsx
• apps/api/src/pdf-v2/templates/classic-ats.tsx
• apps/api/src/pdf-v2/templates/elegant-sidebar.tsx

The processor's language propagation, controller (requestExport), and DTO are all already correct — no other code needed to change.

Regression coverage

Adds apps/api/src/pdf-v2/templates/language-precedence.unit.spec.ts which, for each of the 3 registered templates:

• calls the factory directly (bypassing the react-pdf-loader.ts dynamic-import shim that doesn't work under Vitest's transform),
• renders to a PDF buffer with data.language='de' against a stubbed meta.language='en' (simulating the DE-variant-missing fallback path),
• rasterises text via pdf-parse and asserts German headings (Berufserfahrung, Ausbildung, Fähigkeiten) are present and English equivalents are NOT.

Sanity-checked by reverting the source fix and confirming all 3 tests fail without it.

Out of scope

• Seeding German DB template variants. Removes the noisy Template not found for category … falling back to English warning log and gives PDF metadata a correct language tag, but the template-layer fix is complete on its own — should be a separate cleanup issue.
• application.processor.ts regenerate path (regenerate(), line ~2247) doesn't pass language when re-enqueueing FAILED applications. Pre-existing, separate from the export flow this issue is about.
• Harvard Classic cover-letter meta: _meta underscore-discard — left as-is since the CL body is already language-correct (from LLM) and there's no localized chrome to translate.

Verification

• pnpm vitest run src/pdf-v2/templates/language-precedence.unit.spec.ts → 3 passed
• pnpm lint → 0 lint issues introduced on touched files (the 299 pre-existing warnings live elsewhere)
• Manual repro recommended before merge: pick Harvard Classic + German on a real application, export, confirm German section headings in the downloaded PDF.