Add ADR-0008 for mixed-language Dag processing flow

[jason810496]

• related: AIP-108, AIP-85
• depends on: Derive a mixed-language marker for Dags with task.stub #71213

Design only, no code changes.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 4.6) following the guidelines

[phanikumv]

#71189 also adds an ADR-0008 (0008-taskflow-dag-dsl.md) and appends to this same README line, so whichever of the two lands second needs renumbering to 0009 plus a README fixup. Since #71189 is still draft and this one isn't, simplest is probably to keep 0008 here and renumber there — but either way it's worth pinning down now.

[uranusjr]

I don’t think it makes sense to use the importer here. The importer is designed to be used for dag processing, not on execution time. For stub-based definition, the only the Python importer should be needed; task implementation discovery (finding the JAR to use for a given task) should likely not use AIP-85. A standard may be built later, maybe based on the same interface as AIP-85, but I don’t think using AIP-85 here is a correct choice. Please leave this out; the existing discovery logic based on coordinator configuration should be used.

[jason810496]

To clarify, the entire flow described here occurs during Dag processing. It is not involved in task execution or in discovering an implementation when a task starts.

The proposed use of JavaDagImporter for mixed-language Dags has two goals:

1. Reuse the AIP-85 DagImporter discovery interface instead of introducing a second interface with overlapping discovery responsibilities.
2. Load the Lang-SDK-side Dag definition during processing so it can be compared with the Python stub-based definition. This allows mismatches to be reported as Dag import errors instead of surfacing later during task execution. We need LazyDeserializedDAG here for comparing the attributes, not just the dagId or taskId that the embedded airflow-metadata supports.

The Coordinator appears in the flow only because it provides the deployment-specific artifact location. The design needs to support both DagBundle-based deployment (#70805) and explicitly configured artifact roots. Resolving the Coordinator here does not invoke task execution or move this work to execution time.

[jason810496]

Here're the feedbacks suggested by TP from the offline sync:

• The Lang SDK user interface should be different for the mixed Lang Dag case (e.g. ExternalDag or TaskBuilder instead of DagBuilder etc.)
• Don't treat the mixed Lang Dag artifact same as the native Dag atifact.
• Instead of introducing the is_mixed_language Dag-level argument, we need to adjust the DagFileParsingRequest to make the runtime subprocess propagate the mixed Lang Dag only list.