Fix misleading Calendar Total Runs coloring behavior

[YeonShin]

Updates the Calendar tab Total Runs view to render calendar cell colors based on state severity instead of simple run count aggregation, and adds missing tooltip colors.

Why

As discussed in #66959, I identified a few misleading visual behaviors in the Calendar view.

1. Misleading Cell Rendering (Total Runs mode)

The calendar rendering logic did not differentiate between Actual states (Success, Failed, Running). Instead, it relied on aggregated actual run counts to determine cell intensity and only checked whether pending states (Queued, Planned) existed to apply a mixed pending color.

As a result, cell colors primarily reflected run volume rather than execution severity.

This caused misleading UI behavior where cells containing failed runs could still appear green, making failures less noticeable.

2. Missing Tooltip Colors

CalendarTooltip.ts was missing color definitions for the queued state.

As a result, queued runs could appear with fallback gray colors or visually blend with other states such as Running, creating inconsistent and misleading UI feedback.

Fix

In a monitoring tool like Airflow, severity is more important than frequency.

Even if there are 100 successful runs, a single failure should remain visible.

To address this, I updated the rendering logic in calendarUtils.ts to prioritize colors based on execution severity.

Updated Cell Color Priority

Priority order:

1. Failed
2. Running
3. Success

Rendering examples:

• Success only → Green
• Running only → Cyan
• Failed only → Red
• Success + Failed → Green / Red mix
• Failed + Running + Success → Red / Cyan mix
  • Lower-priority Success is intentionally hidden

Pending State Handling (Queued / Planned)

• Mixed with actual states:
  • Stone (pending color) + highest-priority actual state color
• Pending states only:
  • Solid Stone color

Visuals (Before & After)

Before (Solid Green/Gray hiding errors)	After (Severity-based Mix)

closes: #66959

---

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

• Yes (Gemini 3.1 Pro)

Generated-by: Gemini following the guidelines

---

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

[pierrejeambrun]

Thanks for picking this up — the priority-based rendering is a clear improvement over what's on main, and the screenshots make the case well.

A few things to address before merge

[YeonShin]

Thanks for picking this up — the priority-based rendering is a clear improvement over what's on main, and the screenshots make the case well.

A few things to address before merge

Thanks for the solid review! I’ve addressed all your feedback and pushed the updates after rebasing on top of the latest upstream/main.

Here’s a quick wrap-up of what’s been done:

1. Helper Extraction: Moved the overlapping state-priority rules into a single resolveCellColor helper to clean up both color paths.
2. Clearer Naming: Renamed the ambiguous actual/planned keys to primary and secondary so it’s strictly about visual mapping.
3. Legend Remodel: Instead of leaving it as a follow-up, I updated the CalendarLegend using the new dynamic <LegendIcon />. It now explicitly shows Success, Running, Failed, and Planned samples.
4. Added Tests: Added the requested tests for gradient date spans and multi-state pending branches. I also proactively threw in a defensive test case like handling empty scales ([]) just to be safe.
5. Priority Alignment: I also took the extra step to align actual-vs-actual color blending so that the most critical status consistently claims the primary (top-right) position (failed > running > success) for better visual clarity.

Everything runs clean and all tests are passing green locally. Let me know if this looks good to you!

[pierrejeambrun]

LGTM thanks