Reject zero step in mapped XCom slices

[viiccwen]

closes #70123

A mapped XCom slice with step=0 is invalid, but the endpoint silently treated it as step=1, hiding malformed client requests.

This change returns HTTP 422 with an invalid_step response for every Execution API version. The default step of 1 is now applied only when the parameter is omitted, preserving positive and negative step behavior.

---

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

• Yes - GPT-5.6 Sol

---

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

[viiccwen]

cc @jason810496, @henry3260. 🙌

[henry3260]

Thanks for the fix!

IMO, I don't think this needs a new API version migration though. The old behavior (silently treating step=0 as step=1) is exactly the bug being fixed — preserving it for clients declaring older API versions means their malformed requests keep being silently misinterpreted, which is what #70123 wants to surface.

[viiccwen]

Thanks for the fix!

IMO, I don't think this needs a new API version migration though. The old behavior (silently treating step=0 as step=1) is exactly the bug being fixed — preserving it for clients declaring older API versions means their malformed requests keep being silently misinterpreted, which is what #70123 wants to surface.

Sure, that makes sense. I just updated.