`no_magic_numbers` flags the color components of `Color` and `NSColor`

New Issue Checklist

• I've Updated SwiftLint to the latest version.
• I've searched for existing GitHub issues.

Bug Description

no_magic_numbers exempts the color components of a UIColor initializer, but the check matches that one type name only. SwiftUI's Color and AppKit's NSColor get no exemption, so the same values are reported there.

// No violation, as expected:
let uiKit = UIColor(red: 0.1, green: 0.42, blue: 0.7, alpha: 0.5)

// Three violations:
let swiftUI = Color(red: 0.1, green: 0.42, blue: 0.7)

// Three violations:
let appKit = NSColor(red: 0.1, green: 0.42, blue: 0.7, alpha: 0.5)

SwiftUI spells the opacity component opacity rather than alpha, so that label is not exempt either.

There is a second symptom in AppKit. NSColor names the first component after the color space, so even once the type name is recognised the first component is still reported while the rest are not:

// One violation on 0.1 only:
let color = NSColor(srgbRed: 0.1, green: 0.42, blue: 0.7, alpha: 1)

The same applies to calibratedRed, deviceRed, calibratedWhite, deviceWhite, genericGamma22White, calibratedHue, deviceHue, and to the CMYK components of NSColor(deviceCyan:magenta:yellow:black:alpha:).

$ swiftlint lint --no-cache

Environment

• SwiftLint version 0.65.0
• Xcode 26.5
• Installation method used: building from source
• Configuration file:

opt_in_rules:
  - no_magic_numbers

No nested configurations.

Start with SwiftLint's no_magic_numbers rule and reproduce the examples using swiftlint lint --no-cache. Check the reported violations for SwiftUI Color and AppKit NSColor, including the listed component-label variants. Done means the color component values in those initializers are exempt consistently with UIColor.