Fix #19664: Static extension overload resolution for generic types

[T-Gro]

Fixes #19664

When resolving Type<TArg>.Member(...), the name resolver uses LookupIsInstance.Yes (dot-expression form) but finds static intrinsic members. The extension member lookup then also filters for instance-only extensions, missing the static extension overloads entirely.

The fix detects this mismatch and relaxes the filter to LookupIsInstance.Ambivalent so static extensions are included in overload resolution.

type StaticGeneric<'T> =
    static member Bar() = ()

[<AutoOpen>]
module StaticGenericExtensions =
    type StaticGeneric<'T> with
        static member Bar(_: int) = ()  // Previously: FS0505

StaticGeneric<int>.Bar(42)  // Now resolves correctly

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Warning

No PR link found in some release notes, please consider adding it.

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md	No current pull request URL (#19736) found, please consider adding it

[github-actions]

🔍 Tooling Safety Check — Bypassed (non-fork)

(scanned-sha)1d647200b286e43951fb9462fcf29579bc3809d9(/scanned-sha)

Generated by PR Tooling Safety Check · ● 1.9M · ◷

[T-Gro]

Review – well-targeted fix with clear comments, good regression test, and correct release notes. LGTM.

Summary of the change: When resolving Type<TArg>.Member(...), the resolver enters via dot-expression form (LookupIsInstance.Yes) but TryFindIntrinsicNamedItemOfType returns all matching methods regardless of instance/static. The extension method lookup then applies the strict instance-only filter, missing static extensions. The fix detects when the intrinsic set contradicts the filter and relaxes to Ambivalent, allowing static extensions to participate in overload resolution.

Minor observations (non-blocking):

1. Ambivalent branch in the isAmbivalent check – The LookupIsInstance.Ambivalent -> true case means List.exists returns true for any non-empty minfos, then re-assigns isInstanceFilter = Ambivalent (already its value). This is harmless but reads slightly confusingly. You could simplify to only check the Yes/No cases:
   \\sharp
   let isInstanceFilter =
   match isInstanceFilter with
   | LookupIsInstance.Ambivalent -> isInstanceFilter
   | LookupIsInstance.Yes when minfos |> List.exists (fun m -> not m.IsInstance) ->
   LookupIsInstance.Ambivalent
   | LookupIsInstance.No when minfos |> List.exists (fun m -> m.IsInstance) ->
   LookupIsInstance.Ambivalent
   | _ -> isInstanceFilter
   \
   Purely a readability suggestion – the current code is functionally correct.

2. Property-branch symmetry – The PropertyItem arm (line ~2818) and the RFC-1137 extension-method lookup (line ~2864) both use isInstanceFilter without this relaxation. If a similar scenario can occur with static extension properties on generic types via explicit type args, the same fix may be needed there. Not required for this PR though.

3. Release-notes entry – minor: once merged, add the PR link ([PR #19736](...)) to match the other entries in the file.