UI: 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.