Dedup format specifier locations in computation expressions

[T-Gro]

Fixes #16419

Adds a HashSet guard in TcResultsSinkImpl.NotifyFormatSpecifierLocation to prevent duplicate entries when CE desugaring re-typechecks format strings.

[github-actions]

❗ Release notes required

@T-Gro,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md	No release notes found or release notes format is not correct

[T-Gro]

Clean, minimal fix that correctly addresses the duplicate format specifier issue in computation expressions.

What I verified:

• range is a struct with [<CustomEquality; NoComparison>] and proper Equals/GetHashCode overrides (ignoring synthetic/debug-point bits), so the default HashSet comparer works correctly here.
• The dedup-via-HashSet pattern is already established in this class (capturedNameResolutionIdentifiers, capturedModulesAndNamespaces), so this is consistent.
• No concern about numArgs being silently dropped — a format specifier at a given source location always resolves to the same arity, so deduplicating by range alone is sound.
• Test clearly targets the exact repro scenario (format specifier inside seq CE).

LGTM 👍