Update the comment and bug ID explaining why a workaround in ConfirmationTests is still needed (#1391)

This has no functional change, it just updates the comment and tracking
bug ID explaining why a certain workaround in `ConfirmationTests.swift`
for existential composition of parameterized protocol types is still
necessary.

### Motivation:

I tried removing this workaround recently, since it should no longer be
necessary, but discovered that while the syntax is now valid in Swift
6.2, there's a new blocker—the runtime crash tracked by the new bug ID.
It's helpful to document this so we know why the workaround is still
needed.

Note that even if/when this remaining issue is resolved, this capability
will require a certain minimum OS version on Apple platforms, since the
compiler fix had a runtime component.

### Checklist:

- [x] Code and documentation should follow the style of the [Style
Guide](https://github.com/apple/swift-testing/blob/main/Documentation/StyleGuide.md).
- [x] If public symbols are renamed or modified, DocC references should
be updated.

Author: stmontgomery

Tests/TestingTests/ConfirmationTests.swift

@@ -168,8 +168,10 @@ struct UnsuccessfulConfirmationTests {
 // MARK: -
 
 /// Needed since we don't have generic test functions, so we need a concrete
-/// argument type for `confirmedOutOfRange(_:)`, but we can't write
-/// `any RangeExpression<Int> & Sendable`. ([96960993](rdar://96960993))
+/// argument type for `confirmedOutOfRange(_:)`. Although we can now write
+/// `any RangeExpression<Int> & Sequence<Int> & Sendable` as of Swift 6.2
+/// (per [swiftlang/swift#76705](https://github.com/swiftlang/swift/pull/76705)),
+/// attempting to form an array of such values crashes at runtime. ([163980446](rdar://163980446))
 protocol ExpectedCount: RangeExpression, Sequence, Sendable where Bound == Int, Element == Int {}
 extension ClosedRange<Int>: ExpectedCount {}
 extension PartialRangeFrom<Int>: ExpectedCount {}