WIP Fix #19457: lift CE constructs from plain let RHS in computation expressions

[T-Gro]

Summary

Fixes #19457

When a plain let p = rhs in body appears inside a computation expression, and
hs itself contains CE-only constructs (e.g. let! x = ...; x or do! ...; rest), the compiler incorrectly raised FS0750 ("This construct may only be used within computation expressions").

Fix

Rewrite the expression so those CE constructs are lifted into the enclosing CE, where they desugar correctly. This makes examples like:

\\sharp
task {
let result =
let! x = someAsync
x + 1
return result
}
\\

compile as expected.

Changes

• CheckComputationExpressions.fs: Added logic to detect and lift CE-only constructs from the RHS of plain let bindings inside CEs.
• ComputationExpressionTests.fs: Added tests covering nested let!/do! in plain let bindings within CEs.
• Release notes: Entry added to docs/release-notes/.FSharp.Compiler.Service/11.0.100.md.

Testing

• All new tests pass (ComponentTests Release: 13922 passed, 0 failed)
• SurfaceAreaTest passes (no public API change)
• Fantomas formatting check passes

[github-actions]

❗ Release notes required

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

---

✅ 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]

/azp run fsharp-ci

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[abonie]

This is causing incorrect behavior:

let a = task {
    let b = 999
    let a =
        let! b = Task.FromResult 42
        b
    return (a, b) }

The result of the above is (42, 42) instead of (42, 999)

[abonie]

As per my comment above, the shadowing seems to not work correctly after this change

[T-Gro]

Fixed the shadowing issue identified by @abonie. The lift now checks whether any variables introduced by lifted bindings (let!/use!/let) in the RHS would appear in innerComp. If so, the lift is skipped and FS0750 is produced instead of silently incorrect behavior.

Test case from the review (let b = 999; let a = let! b = ...; b; return (a, b)) now correctly rejects the lift with FS0750, since the lifted b would shadow the outer b used in return (a, b).

[T-Gro]

I am not happy about it at all, moving to draft and will find a different approach.

[T-Gro]

/azp run fsharp-ci

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[T-Gro]

Fixed the shadowing issue identified by @abonie. The lift now refuses to proceed when names introduced by lifted CE bindings (let!/use!) would appear in the continuation (innerComp). In that case, the code falls through to the standard FS0750 error path.

The reviewer's test case:
\\sharp
task {
let b = 999
let a =
let! b = Task.FromResult 42
b
return (a, b)
}
\
Now correctly produces FS0750 instead of silently giving (42, 42).

Lift still works when there's no shadowing conflict (e.g., \let a = let! b = ...; b; return a).