Link dbt Cloud runs to the triggering Airflow task via OpenLineage

[mobuchowski]

dbt Cloud does not natively propagate the OpenLineage parent run of the Airflow task that triggered a job, so a triggered run has no stored link back to that task. Any tool that reads dbt Cloud runs on their own therefore sees them as isolated jobs, with no way to attach them to the Airflow run that started them. This adds an openlineage_inject_parent_job_info option to DbtCloudRunJobOperator. When enabled, it writes the task's OpenLineage parent and root run identifiers, as JSON, into the triggered run's cause field, so a consumer reading dbt Cloud runs can parse them and rebuild the ParentRunFacet that links the run to its Airflow task.

It is conceptually the same thing we've added in #44477 #64513 or #64807 but using different, dbt cloud specific mechanism.

The option defaults to the existing openlineage.spark_inject_parent_job_info config value, matching the convention already used by the Glue and EMR operators. Because dbt Cloud limits cause to 255 characters, the payload is trimmed to fit: the parent identifiers are always kept, the root block is dropped if the two together are too long, and injection is skipped if even the parent alone does not fit. When injection is enabled the cause is replaced entirely with these identifiers rather than the human-readable trigger reason, since the correlation is the point of the option.

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

• Yes (please specify the tool below)

Generated-by: Claude Code (Opus 4.8) following the guidelines

[kacpermuda]

Left two comments, lgtm overall

[kacpermuda]

I know that every character counts since the limit is low, but maybe we should add encapsulating {"openlineage": {"parent"...}} dict? Without the word openlineage, parent and root can be confusing for reader. But, if somebody sets it to True, they usually know what they're doing. Something to consider.

[mobuchowski]

I think we're too constrained here unfortunately :(