fix(iswf): Fixes issue with old Sentry App rules failing to serialize when alert schema is removed

[GabeVillalobos]

Our label rendering logic for Sentry App rules seems to rely on a schema component being defined for alert rule creation, which is reasonable.

Unfortunately, this also breaks rule API queries if this schema component is removed. This PR fixes the issue by defaulting to the Sentry App name when a schema title is not availble.

To reproduce:

1. Create a valid Sentry App, you need to have an active server running that can process webhooks
2. Add the schema for adding alert rules
3. Create a new alert rule. Note: this won't appear as an option if your sentry app server isn't actively running and handling requests
4. Configure the alert rule and trigger it with the test button
5. Remove the schema for adding alert rules

Resolves: ISWF-2340

[linear-code]

ISWF-2340 Investigate 400 error on Dropbox API alert actions

[ceorourke]

Fix seems reasonable as long as we're ok with this behavior - I guess the alternative is a clearer error message saying they need to put the schema back.

[github-actions]

Backend Test Failures

Failures on a0dc941 in this run:

tests/sentry/api/serializers/test_rule.py::WorkflowRuleSerializerTest::test_sentry_app_render_label_no_alert_rule_action_schema — log

[gw1] linux -- Python 3.13.1 /home/runner/work/sentry/sentry/.venv/bin/python3
tests/sentry/api/serializers/test_rule.py:899: in test_sentry_app_render_label_no_alert_rule_action_schema
    self.assert_equal_serializers(rule)
tests/sentry/api/serializers/test_rule.py:169: in assert_equal_serializers
    assert len(rule_actions) == len(workflow_actions)
E   AssertionError: assert 0 == 1
E    +  where 0 = len([])
E    +  and   1 = len([{'id': 'sentry.rules.actions.notify_event_sentry_app.NotifyEventSentryAppAction', 'name': 'Test Application', 'sentryAppInstallationUuid': 'da050296-6218-41a5-bf9a-3857b4eed425'}])

[sentry]

Bug: The code breaks after finding the first alert-rule-action component, potentially missing a title defined in a subsequent component and causing inconsistent behavior with other parts of the system.
_{Severity: LOW}

Suggested Fix

Modify the loop in sentry_app_issue_alert_handler.py to match the logic in notify_event.py. Instead of breaking on the first alert-rule-action component, iterate through all of them until a non-null title is found. This will ensure consistent title resolution across the application.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location:
src/sentry/notifications/notification_action/issue_alert_registry/handlers/sentry_app_issue_alert_handler.py#L109-L110

Potential issue: There is a behavioral inconsistency in how the alert rule action title
is resolved. The new code in `sentry_app_issue_alert_handler.py` iterates through a
Sentry App's components and breaks after finding the first one with type
`alert-rule-action`. It then checks for a `title`. If this first component has no title,
it defaults to `sentry_app.name`. However, other parts of the system, like
`notify_event.py`, continue iterating to find any component with a title. This can lead
to different results if a Sentry App has multiple `alert-rule-action` components and the
first one lacks a title while a subsequent one has it.

_{Did we get this right? 👍 / 👎 to inform future reviews.}