fix(a11y): drop assertionFailure for multiple Receivers in deferral container

[RoyalPineapple]

Summary

Removes the assertionFailure in AccessibilityDeferral.DeferralContainerView.updateAccessibility() that aborted debug builds when the container observed more than one Receiver.

The accompanying safe recovery — clearing each receiver's content via apply(content: nil, frameProvider: nil) and returning early — is preserved, so the multiple-Receiver case now degrades gracefully in both debug and release. The duplicate-source-identifier assertionFailure later in the same method is intentionally kept, since that remains a genuine misconfiguration worth flagging.

Why

The >1 Receiver state is an expected transient, not a misconfiguration: during a reentrant Blueprint update (a forced layoutBelowIfNeeded mid-update) the container can momentarily see both the outgoing and incoming Receiver before the hierarchy settles. This trapped under -Onone, crashing snapshot tests (e.g. LinkDebitCardScreenSnapshotTests.test_view()) during BlueprintView layout. The settled layout pass re-runs updateAccessibility() with the single surviving Receiver, so dropping the assertion lets the existing recovery handle the transient cleanly. This completes the trajectory of the prior commits that replaced the original fatalError with assertionFailure + safe recovery.

Changes

• Remove the multiple-Receiver assertionFailure, keeping the existing safe recovery.
• Add a comment on the receivers.count <= 1 guard documenting why >1 is tolerated, so the assertion isn't re-added.
• Add a CHANGELOG entry under [Main] → Fixed.

[RoyalPineapple]

🤖 Closing in favor of #620 (Rob's fix), which makes the same assertionFailure removal and adds a regression test for the duplicate-receiver case. Consolidating on that one.