Fix accessibility and type-matching for generic extension method lookups

[evgTSV]

Fixes #19349

-> Fix accessibility and type-matching for pattern-based extension lookups (CE, Dispose, etc.)

Summary

This PR fixes an issue where pattern-based extension method lookups (specifically for Computation Expressions and use bindings) would incorrectly resolve methods that are either inaccessible (private/internal) or belong to incompatible types.

Problem

Previously, the compiler's name resolution for CE-specific methods (like Bind, Delay, Run, etc.) and the Dispose pattern for resource cleanup was overly optimistic. It often bypassed accessibility checks, leading to incorrect method resolution or even compilation of calls to private extension methods from outside their scope.

Checklist

• Test cases added
• Release notes entry updated:

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md

[evgTSV]

It seems that my changes broke FSharp.Core. I suppose that we have to adjust type equality check to work with the core code.

[T-Gro]

⚠️ Automated Copilot Review — AI-assisted initial review. Feedback welcome.

[Breaking Changes] IsExtensionMethCompatibleWithTy has a logic gap in the TType_var branch: when the extension method's this parameter is a type variable with no CoercesTo constraint (unconstrained generic, or constrained only by struct/member/equality), the current code returns false and the method is silently excluded. This affects C# extensions like public static T Run<T>(this T x) and F# extensions with (this: 'T) or (this: 'T when 'T : struct). A type variable with no CoercesTo bounds should match any target type — the [] -> true fallback is missing.

[Test Coverage] All CE extension method tests use #SomeType (which always has a CoercesTo constraint). A test with a genuinely unconstrained 'T on the this parameter would catch the above bug.