fix(print): Print always renders live; snapshot mint + mail attachment language is declarative (#6491)

[delchev]

Closes #6491.

What

Print always renders LIVE. The stored-copy redirect (#6359) is removed from the generated Harmonia document and manage pages: the Print button unconditionally runs the dynamic flow — fetch the CMS print languages, one prints directly, several pop the picker (Region & Language pre-sorts the suggested default). The immutable issued copy stays first-class on its own surface: the read-only Snapshot files panel keeps Download and gains a per-version inline Open action (detailPanel.openHref → the generated download route with ?disposition=inline, which the controller template now honors).

The mint/attachment language is declarative. Nothing hardcodes "en" anymore:

• A function: Snapshot child accepts language: <code> (fixed) or languageFrom: <master relation>.<string field> (per record — the counterparty decides the document's language; cross-model targets resolve through the owner's model like every other cross-model reference, and a path that stops resolving fails the glue pass loudly instead of minting wrong-language copies).
• The notify block's attach: print gains the same languageFrom next to its existing language: (all four call sites: notifications, schedules, transitions, process-step sends). An unresolvable path is reported as a generate warning and the mail is dropped, per the notify conventions.
• Absent both knobs, the render falls back at run time to the first entry of the tenant-resolved DIRIGIBLE_APPLICATION_LANGUAGES via the new sdk.print.Print.defaultLanguage() — so a bg-configured tenant mints bg copies with no intent change.

The glue (SnapshotSupport, NotifySupport) pre-renders the language as a Java expression plus an optional languageSource/attachLanguageSource relation load (the expansions convention); the Velocity templates stay shape-only. The parser validates the knobs (Snapshot-only at entity level, attach: print-only on notify blocks, mutual exclusivity, one-hop path to a string field).

Tests

• SnapshotLanguageIntentTest — 9 parser cases (valid shapes + every misuse).
• GlueSendDocumentTest — the pre-rendered language expressions (literal / fallback) + the languageFrom load coordinates.
• IntentEngineIT — the generated OrderSnapshotGenerator resolves languageFrom: customer.locale (master load → FK → locale → fallback) and renders with the resolved language; the document page contains no stored-copy redirect and the files panel offers the inline Open action.
• IntentEmissionCoverageIT — the transition notify carries languageFrom: Person.locale; the generated sender loads the language source off the record's FK and falls back to the application language set. The fixture is compiled and published end-to-end, so the new generated code paths run through real javac.
• PrintRenderIT.defaultLanguageRenderPicksTheConfiguredLanguage — the outermost runtime proof of the fallback: with DIRIGIBLE_APPLICATION_LANGUAGES=bg,en and ONLY a bg template seeded, a render through Print.defaultLanguage() returns a PDF over HTTP in tenant scope — resolving any other language would fail loudly (no such template), never return a wrong-language PDF.

Unit suite: engine-intent 295/295 green; formatter + release-profile javadoc validated on the touched modules.

🤖 Generated with Claude Code