Let a Dag importer find the coordinator that parses its files

[jason810496]

Stack (bottom to top): #74042, #74035, #74043, #74036, #74037, #73845, #73846, #73847

Why

To parse native Dags, the Dag importer that claims a file has to find the coordinator that parses it. It looks in [sdk] coordinators, so a runtime is still declared in one place.

What changes

• CoordinatorDagImporter is the base class for a runtime's Dag importer. A subclass sets coordinator_classpath, and get_parsing_coordinator() returns the coordinator of that class that parses its files in its Dag bundle.
• With no coordinator of that class, the importer is not registered. With one, it parses the importer's files in every Dag bundle. With several, the new [sdk] dag_bundle_to_coordinator must map the bundle to one of them, or get_parsing_coordinator() raises InvalidCoordinatorError.
• DagImporterRegistry.from_config(bundle_name) registers each importer in COORDINATOR_DAG_IMPORTERS that has a coordinator. The tuple is empty until Parse native Java Dags and show their source #74036 and Parse native TypeScript Dags with the Node coordinator #74037 add the Java and Node importers.
• SubprocessCoordinator.parse_dag(...) replaces the calling process with the runtime that parses one Dag file.
• A Lang-SDK runtime gets the resolved [api] base_url, [operators] default_deferrable and [triggerer] queues_enabled in its environment, like the log levels.

With two JavaCoordinators, jdk-11 and jdk-17, tasks still follow their queue and the new option picks which one parses each Dag bundle:

[sdk]
queue_to_coordinator = {"legacy-java": "jdk-11", "modern-java": "jdk-17"}
dag_bundle_to_coordinator = {"dags-folder": "jdk-17"}

---

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

• Yes, with help of Claude Code Opus 5.5 following the guidelines

[jason810496]

Thanks for the reivew.

[uranusjr]

Two minor points needing resolution. Generally looks good to me.