fix(msteams): Prevent AssertionError when rule lacks legacy_rule_id

[sentry]

This PR fixes an AssertionError occurring in the MS Teams webhook handler (/extensions/msteams/webhook/).

The root cause was that build_rule_url in src/sentry/integrations/messaging/message_builder.py unconditionally called get_key_from_rule_data(rule, "legacy_rule_id"). The get_key_from_rule_data function contains an assertion that value is not None, which would fail if the rule.data.actions[0] dictionary did not contain the legacy_rule_id key. This happened for certain older rules or rules without this specific field set.

The build_footer function, which calls build_rule_url, already correctly determines the rule ID using get_rule_or_workflow_id, which includes fallback logic (e.g., to str(rule.id)).

The fix modifies build_rule_url to accept the already-resolved rule_id as a parameter. build_footer now passes this safely resolved rule_id to build_rule_url, thus bypassing the problematic assertion and preventing the AssertionError.

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

Fixes SENTRY-4EPX

_{Comment @sentry <feedback> on this PR to have Autofix iterate on the changes.}

[sentry-warden]

build_rule_url fallback still exposes AssertionError for Slack and notification callers

The build_rule_url fallback to get_key_from_rule_data preserves the same AssertionError in Slack build_slack_footer and notification get_notification_title paths, which still call the function without passing the safely resolved rule_id.

Evidence

• build_slack_footer in slack/message_builder/util.py calls get_rule_or_workflow_id(rules[0]) safely, then calls build_rule_url(rules[0], group, project) without the resolved value.
• get_notification_title in notifications/notifications/rules.py follows the same pattern, calling build_rule_url without the resolved value.
• When get_rule_or_workflow_id falls back to str(rule.id), it still returns the "legacy_rule_id" key, causing both callers to enter that match branch.
• build_rule_url then calls get_key_from_rule_data(rule, "legacy_rule_id"), which asserts value is not None and raises AssertionError when the rule data lacks that key.

_{Identified by Warden · sentry-backend-bugs · 4WC-TWT}