Document that connection secrets without conn_type remain supported

[henry3260]

Why

Connection secrets in JSON format could omit conn_type. Although the secrets backend deserialized those values, the Execution API requires a connection type and the task could ultimately receive a misleading “connection not found” error.

This addresses the conn_type portion of related: #57864.

What

• Reject JSON connection secrets whose conn_type is missing, null, empty, or whitespace-only.
• Raise a clear ValueError before constructing an incomplete Connection.
• Add regression coverage for each invalid conn_type value.

---

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

• Yes (please specify the tool below)

---

• 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.

[Vamsi-klu]

Went through _deserialize_connection_value and the new guard reads correct to me. Good call accepting uri as an alternative rather than requiring conn_type outright, since from_json passes a bare uri to the constructor which routes through from_uri and parses the scheme into the conn_type, so those blobs still build a usable connection and the {"conn_type": null, "uri": ...} test covers exactly that. Raising a ValueError up front is a clear improvement over the misleading connection not found error the PR describes. Only nit, you json.loads(value) in the guard and then from_json parses the same string again, negligible for a small secret blob so I wouldn't bother.

#69780 (comment)