Fix ValueOption optional args with ?param caller syntax

[T-Gro]

Fix caller-side ?name = expr syntax for ValueOption optional parameters when SupportValueOptionsAsOptionalParameters is enabled.

Fixes #19711

[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

[T-Gro]

Clean, well-scoped fix. The root cause was that TcMethodApplication_SplitSynArguments eagerly constrained the caller argument type to option<_> when the ?param = expr syntax was used, preventing ValueOption from ever unifying correctly.

The fix correctly gates on SupportValueOptionsAsOptionalParameters to leave the type as a fresh inference variable when the feature is enabled, letting later unification in AdjustCalledArgTypeForOptionals (CalleeSide branch) match the actual declared parameter type — whether option<_> or voption<_>.

Key points verified:

• Correctness: The CalleeSide branch at line 382 passes through calledArgTy unchanged (which already handles both option/voption), so the deferred unification naturally resolves to the right wrapping type.
• Backwards compat: LangVersion < 10 preserves old behavior (early option<_> constraint).
• Test coverage: Methods, constructors, both option variants, and langversion gating are all exercised.
• No inference regressions: Since None/Some and ValueNone/ValueSome are unambiguous on their own, removing the early constraint doesn't create inference ambiguity for practical cases.

LGTM ✅

[abonie]

Any specific reason to underspecify the diagnostic message here? Other negative tests in this file are way more specific, would be safer to ensure the expected error is triggered.