Add accessibilityLabel override to AttributedLabel

[RoyalPineapple]

Adds an optional accessibilityLabel: String? to the AttributedLabel model so consumers can override or suppress the label that is otherwise derived automatically from the displayed text. nil (the default) preserves today's text-derived behavior, a non-nil value overrides it, and "" suppresses the spoken label entirely — useful when the text is surfaced through accessibilityValue/accessibilityHint and the label is merged into a combined accessibility element, so the content isn't announced twice. The change is purely additive: no existing call sites change. Internally, the expensive text-derived label is cached behind the existing text-change guard in LabelView while the override is applied on every update, so an override change takes effect even when the text is unchanged, with no perf regression. Adds tests covering the default/override/suppression cases, application without a text change, and suppression flowing through AccessibilityComposition.

[robmaceachern]

lgtm

[robmaceachern]

🤖 (on Rob's behalf) The String? shape is the right call here — it's consistent with the sibling accessibilityValue/accessibilityHint on this model, with AccessibilityElement.label, and with UIKit's own accessibilityLabel (nil = derive). And empty-string-means-absent is already the house convention: AccessibilityCombine documents that an element isn't accessible "unless it has a non-nil and non-empty label/value/hint," which is exactly why the composition test works. So the ""-suppresses behavior isn't a novel magic value — it fits existing precedent. I'd keep it over an enum, which would make this the only accessibility prop that isn't a plain optional string and would lose the x.accessibilityLabel = someOptionalString drop-in ergonomics.

One small discoverability nit: ""-as-suppression isn't legible at the call site, and a future reader could "fix" a bare "" thinking it's a mistake. Consider a named constant so intent is greppable:

extension AttributedLabel {
    /// Assign to `accessibilityLabel` to suppress the spoken label entirely.
    public static let suppressedAccessibilityLabel = ""
}

Non-blocking — the doc comment already covers it well.

[robmaceachern]

🤖 (on Rob's behalf) Good that this is called out inline — the whole suppression story rests on this undocumented UIKit behavior (an explicitly-set "" is returned verbatim rather than falling back to .text). That makes this test load-bearing rather than incidental: if a future OS changed the fallback, ""-suppression would silently break. Worth keeping and maybe a one-liner in the test name/doc flagging it as guarding a UIKit assumption.