Fix Calendar view hanging for Dags with high-frequency cron schedules

[theJohnnyBrown]

The Calendar view's planned-runs computation for cron timetables iterates croniter until the year boundary with no cap, while the generic-timetable path has always stopped at MAX_PLANNED_RUNS (2000). The scan runs synchronously in the request handler on every calendar request, and the date-range filter does not bound it (filtered dates are skipped, not stopped at).

Measured cost of the unbounded loop per GET /ui/calendar/{dag_id} request:

Schedule	Iterations to year end (from early Jan)	Time
*/5 * * * *	~104k	~2 s
* * * * *	~520k	~7 s
* * * * * * (seconds cron)	~31.5M	~5.5 min of CPU

Any user with Dag read access triggers this just by opening the Calendar tab of such a Dag, which can pin an API server worker.

This applies the same MAX_PLANNED_RUNS cap the generic path has used since the endpoint was added (#52748), via itertools.islice. Planned cells for high-frequency crons are now shown up to 2000 runs ahead, consistent with what an equivalent timedelta-scheduled Dag already does.

The new test fails without the fix (the request returns ~300k planned runs after ~4.5 s) and passes with it; all existing calendar tests pass.

---

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

• Yes — Claude Code (Fable 5)

Generated-by: Claude Code (Fable 5) following the guidelines

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack