[F# 10.1 / FCS 43.12] Signature-conformance warning FS3218 no longer surfaced in IDE (per-file) check results — intentional?

[Thorium]

Between FCS 43.10.101 and 43.12.201 (i.e. the F# 9 → F# 10 generation), the signature/implementation argument-name-mismatch warning FS3218 ("The argument names in the signature '…' and implementation '…' do not match…") stopped appearing in the IDE / library check results for the implementation file, while it is still emitted by a full command-line build.

Is this an intentional change to where signature-conformance diagnostics are reported (e.g. only during whole-project compilation, not in per-file ParseAndCheckFileInProject results), or a regression?

FsAutoComplete relies on this diagnostic to power a "rename signature" code fix, and the change silently disables that fix.

** Environment **

	Works	Broken
FSharp.Compiler.Service	43.10.101	43.12.201
FSharp.Core	10.0.101	10.1.201
.NET SDK	—	10.0.100

OS: Linux (also reproduces via the standard FCS APIs, not editor-specific).

** Repro steps **

Two-file project with mismatched parameter names between signature and implementation:

Code.fsi

module Code

val f: value1: int -> int

Code.fs

module Code

let f v1 = v1 + 1

repro.fsproj → net8.0, compiling Code.fsi then Code.fs.

Command-line build (warning IS emitted)

$ dotnet build
Code.fs(3,7): warning FS3218: The argument names in the signature 'value1' and
implementation 'v1' do not match. The argument name from the signature file will
be used. This may cause problems when debugging or profiling.

IDE / library check (warning is NOT present)

When the same project is loaded and the implementation file is checked through the FCS APIs used by editors (ParseAndCheckFileInProject / project check), the returned diagnostics for Code.fs do not include FS3218 on 43.12.201.
On 43.10.101, FS3218 is present in those results.

(In this case it reproduces against both the background and transparent checkers.)

** Expected vs actual **

• Expected (and behaviour on 43.10.101): FS3218 appears in the implementation file's check results, so editors can offer signature-related quick fixes.
• Actual (43.12.201): FS3218 absent from the per-file check results (still emitted by full compilation).

Questions

1. Is this relocation/removal of FS3218 from per-file IDE check intentional in F# 10?
2. If intentional, what is the recommended way for tooling to obtain signature-conformance diagnostics in an IDE scenario now?

Possibly-related

Two signature-file code fixes (AddBindingToSignatureFile / AddTypeAliasToSignatureFile) stop producing edits for nested-module and display-context cases on 43.12.201 (they work on 43.10.101). These use mfv.GetValSignatureText(displayContext, range) and walk the sig/impl syntax trees. I don't know if the diagnostic change above and these are the same root cause (changes to sig/impl handling in the IDE pipeline).