paket dependency manager doesn't work out of the box in VS, but it does if compiles with VS

When I pull the release of FSharp.DependencyManager.Paket.dll from https://github.com/fsprojects/Paket/releases and drop it next to the location it is required under `dotnet fsi` (under the dotnet sdk folder, next to the nuget extension), it just works.

However, when I attempt to do so, in order for VS to pick it up, dropping under the commonextensions/microsoft/fsharp folder, VS doesn't pick it up.

**Repro steps**

* download FSharp.DependencyManager.Paket.dll from https://github.com/fsprojects/Paket/releases
* (§) drop it in your VS installation (C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\CommonExtensions\Microsoft\FSharp for example)
* open a script with `#r "paket: nuget Foo"` in it

**Expected behavior**

Typechecks or complains about the file being locked by the OS, and guide the user to fix it.

**Actual behavior**

Complains about the extension "paket" not being present.

**Actual manual fix**

check that the extension assembly file is not blocked by the OS (due to being downloaded from browser or other reasons).

**Initial workaround**

* https://github.com/fsprojects/Paket/
* open https://github.com/fsprojects/Paket/blob/master/src/FSharp.DependencyManager.Paket/FSharp.DependencyManager.Paket.fsproj in VS
* compile to your taste
* !!!!???? (§) (deploy in VS following the above steps, which are a bit voodoo for end users until we do something around #8880)
* profit

[FSharp.DependencyManager.Paket.release.zip](https://github.com/dotnet/fsharp/files/8375342/FSharp.DependencyManager.Paket.release.zip)

**Related information**

It always behaved this way, it is not something which broke due to a change, but it should be fixed if possible.

I suspect it impacts any other extensions than the one which Microsoft ships, I don't know why it works out of the box in the dotnet sdk but not in VS.