Issue summary:

When a Forge macro defines an adfExport function and returns null, Confluence falls back to natively rendering the macro's live view for the export (per the fix in CONFCLOUD-83083). This native render is intentionally indistinguishable from a normal page view, and no signal is passed to the running macro (or its backend) indicating that the current render is part of an export.

As a result, an app cannot adjust its behavior when its content is being rendered for export rather than for interactive viewing. Concretely, apps cannot skip work that is pointless or harmful during export (for example generating and fetching an on-demand image), and cannot strip interactive-only affordances (links, info icons, hover controls) that serve no purpose in a static PDF or Word output.

The only export-related signal today is payload.exportType inside adfExport, but that is only available on the ADF-return path, not the null native-render path. It is also drawn from the internal ConversionContextOutputType enum and can arrive as display, preview, email, feed, or html_export in addition to pdf/word/other, so it is not a reliable "a user is exporting" indicator either. There is no equivalent to macro.isConfiguring (the existing config-editor context flag) for the export/render context.

Steps to reproduce:

1. Create a Forge Confluence macro that renders content in its live view (for example an image fetched on demand from the app backend, plus interactive links or info icons).
2. Add an adfExport function to the manifest that returns null, so exports use native high-fidelity rendering.
3. Add a macro instance to a page and export the page to PDF (and/or Word).
4. Observe within the macro's render code and the app backend that there is no reliable, documented signal indicating the render is happening for an export.

Expected results:

A documented, supported way for a Forge macro to know it is being rendered in an export/print context on the native render path. For example, an isExport (or render-context/output-type) value exposed in the macro's product context, analogous to the existing macro.isConfiguring flag, and ideally propagatable to the app backend so it can respond differently for export renders.

Actual results:

On the null native-render path there is no export-context signal at all. The only related signal (payload.exportType) exists only on the ADF-return path and is derived from an internal render enum that also covers non-export contexts, so it cannot be treated as a dependable export indicator. Apps are left with unsupported and brittle workarounds (for example inspecting user-agent, IP, or request headers from the headless renderer) or must accept that export-only adjustments are not possible on the native path.

Workaround:

No reliable supported workaround exists for the native (null) render path. Apps that need export-specific output can instead return tailored ADF from adfExport (where payload.exportType is available), but that path forgoes native high-fidelity rendering and, for external media, introduces the external-media badge (ECO-1323) and image-load limitations (CONFCLOUD-82718). Request-sniffing of the headless renderer is unsupported and unreliable.