fix: add empty alert selector fallback

[tk3fftk]

What type of PR is this?

• Refactor
• Feature
• Bug Fix
• New Query Runner (Data Source)
• New Alert Destination
• Other

Description

This PR fixes a critical backward compatibility issue in the Alert system where alerts created before the selector feature was introduced would crash when rendering templates due to a missing selector field in options.

Problem: When the selector feature was added to alerts, existing alerts in the database lacked the selector field in their options JSON. This caused old (no selector) alerts were not triggered.

Solution:

• Changed direct dictionary access self.options["selector"] to safe access self.options.get("selector", "first") with "first" as the default fallback
• Added comprehensive backward compatibility tests to ensure legacy alerts work correctly

Impact: This fix ensures that all existing alerts continue to function properly without requiring database migration, while maintaining full compatibility with the new selector functionality.

How is this tested?

• Unit tests (pytest, jest)
• E2E Tests (Cypress)
• Manually
• N/A

Added two new test cases:

• test_render_template_with_legacy_alert_without_selector: Verifies template rendering works with legacy alerts
• test_evaluate_legacy_alert_without_selector: Verifies alert evaluation works with legacy alerts

Related Tickets & Documents

This addresses the backward compatibility issue discovered in commit fc1e1f7 where the selector feature was added without proper handling of existing alerts.

• adding migration pull request is still open Add migration to set default alert selector #7197

Mobile & Desktop Screenshots/Recordings (if there are UI changes)

[eradman]

Another solution to this was one I proposed in #7197

[tk3fftk]

@eradman Well, I found that Pull Request and it has not been merged yet about a year 😭. (and thank you for your migration query 🙏 It was very useful for our quick fix)
That's why I created this Pull Request. If you and redash team have a plan, I will close this pull request.

[eradman]

@tk3fftk thanks for bringing attention to this. I'll leave this PR open for now and see if someone has time to review both solutions.

[eradman]

Closing in favor of #7475