Document how clearing tasks works with task state store on durable operators

[amoghrajesh]

---

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

• Yes (please specify the tool below)

Same as #71356 but for providers.

Clearing a task whose external job already succeeded returns without resubmitting, since state store rows survive a clear. Rather than duplicate the explanation per operator, each doc gets a one-line pointer to the shared core-concepts writeup, plus the clear_on_success setting that restores "clearing always resubmits."

Touches SparkSubmitOperator, RedshiftDataOperator, DatabricksRunNowOperator, DatabricksSubmitRunOperator, and SnowflakeSqlApiOperator.

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[uros-b]

@amoghrajesh Please note that the PR title got cut-off mid word:

Document how clearing tasks works with task state store on durable operators

[jason810496]

How about waiting for #71356 (review) discussion first before landing into each providers.

Additionally, would it make sense to add the prek script with <-- auto sync by ... --> like marker to prevent drift?

[Lee-W]

agree we can wait for another PR to be merged. but I don't think we really need a prek hook for that. overkill IMO

[amoghrajesh]

Yeah I think we don't need a prek hook - seems like an overkill.

[amoghrajesh]

@amoghrajesh Please note that the PR title got cut-off mid word:

Document how clearing tasks works with task state store on durable operators

Thanks for letting me know, thanks!

[jason810496]

How about mentioning something like "we're only able to reconnect back to the external job if it's deferred task deferrable=True, see more in ... <link to the core docs that we just settled in #71356 >"?

[amoghrajesh]

Added. Each doc now says explicitly that reconnect-on-clear is most reliable for deferred tasks (deferrable=True), since clearing an actively-polling synchronous task can cancel the job via on_kill before the next attempt gets a chance to reconnect. Links to the caveat in core-concepts/resumable-tasks (from #71356).

[amoghrajesh]

@jason810496 @uros-b I added the reference and suggestion as suggested. Can you take a look?

[jason810496]

Thanks for the update.