.HasItemAt(i).Satisfies() loses specialised assertion source for item

[thomhurst]

Related: #5703, #5704, #5705 (same pattern).

Problem

.HasItemAt(index).Satisfies(item => ...) passes a generic IAssertionSource<TItem> into the lambda. When TItem is a string, collection, dictionary, or set, specialised assertion methods are unreachable.

Repro

// IList<string>
await Assert.That(list).HasItemAt(0).Satisfies(s => s.Contains(\"foo\")); // fails: string-specific Contains not on IAssertionSource<string>

// IList<List<int>>
await Assert.That(listOfLists).HasItemAt(0).Satisfies(l => l.HasCount(3)); // fails

Affected signatures

• TUnit.Assertions/Conditions/ListAssertions.cs:126 Satisfies(Func<IAssertionSource<TItem>, Assertion<TItem>?> assertion, ...)
• TUnit.Assertions/Conditions/ReadOnlyListAssertions.cs:129 — mirror signature

Proposed fix

Add specialised Satisfies overloads on the item-at helper type, keyed on TItem shape (string / IEnumerable / IDictionary / ISet / ...), passing the specialised source into the lambda. Use OverloadResolutionPriority for compiler steering.

Acceptance

• Specialised assertions reachable inside the .HasItemAt(i).Satisfies(...) lambda for string/collection/dict/set items.
• Same on ReadOnlyListAssertions path.
• Tests cover each specialised element shape, on both list and read-only-list sources.