EF Core DbContext Connection - Could Not Load File or Assembly

We have just begun migrating all of our applications from .NET Framework (v4.6.2) to .NET Core (v10) and have made the first attempt at connecting LINQPad back up to the first application, but I am receiving the following:

Error Testing Custom EF Core Connection: Could not load file or assembly 'Microsoft.Extensions.Logging.Abstractions, Version=10.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.

We are using the portable version of LINQPad 9 (v9.6.6 (X64)_, licensed as Premium Edition. LINQPad9-x64.exe copied and renamed to LPRun9.exe as per the !!info for xcopy deployments.txt file.

I mention the portable version because this might matter. We're in the process of getting approval to get LINQPad 9 in Software Center for download/install, but getting new software approvals is like moving a mountain. So we're trying the non-installed version at the moment.

Moving on...

The Microsoft.Extensions.Logging.Abstractions package is a transitive dependency of our projects/solution. When working through the "EF Core DbContext Connection" dialog, it is not listed in the NuGet packages that LINQPad auto-finds that it says it needs to download.

I started-from-scratch:
1. Closed LINQPad
2. Cleared any locally-retained NuGet packages by clicking the "Clear NuGet local resources" button in Visual Studio's options
3. Closed Visual Studio
4. Deleted all bin and obj files for each project in our solution (we have a "Web" project for MVC/WebAPI and we have a "Core" project for all of the business logic)
5. Deleted the packages folder (our solution is setup for central package management)
6. Cleared all globally-retained NuGet packages with dotnet nuget locals global-packages --clear; verified %USERPROFILE%/.nuget was empty
7. Launched Visual Studio, opened our solution and ran a "Rebuild Solution"
8. Opened our portable version of LINQPad -> Add Connection... -> Entity Framework Core (3.x -> 10.x)
9. Clicked "Browse" for the "Path to Custom Assembly" field and selected our "Core" project's DLL (where EF is defined/used); the "Confirm Package Download" dialog appears, in which Microsoft.Extensions.Logging.Abstractions is not listed
10. Click "Yes" to download missing packages; and once completed, confirmed that the %USERPROFILE%\.nuget\packages folder is created and filled with the same packages listed in the dialog; Microsoft.Extensions.Logging.Abstractions still missing
11. Back in the "EF Core DbContext Connections" dialog, our DbContext has been automatically found and we simply click "OK" on the dialog that informed us of this
12. We indeed have a (sole) constructor that accepts DbContextOptions, so this (the only selectable) option is selected
13. We select the Microsoft.EntityFrameworkCore.SqlServer provider and enter our connection string
14. After entering a friendly name for the connection, we test the connection... and we get the "could not load" message at the top of this post

Figuring LINQPad is complaining that the DLL can't be found in the global directory for NuGet packages, I figured I'd use LINQPad to force its existence:
1. I closed the connection-creation dialog and pressed F4 while in a script editor window
2. I clicked the "Add NuGet..." button
3. In the "Search online" field, I searched for Microsoft.Extensions.Logging.Abstractions and used the "Add to Script" dropdown to specify that v10.0.0 be added
4. I verified that the %USERPROFILE%\.nuget\packages\Microsoft.Extensions.Logging.Abstractions folder appeared with a fully-filled 10.0.0 folder inside
5. I performed steps 3 and 4 again for v10.0.5, since our projects are up-to-date with pulling in v10.0.5 of Microsoft's NuGet packages
6. I closed LINQPad, opened it again and tried again to add the connection using all the same steps above and I still get the "could not load" message again

Does anyone have any ideas on why this transitive dependency is not being found by LINQPad? It may not even be the only one as it could be that this is just the first one we're encountering as LINQPad tries to resolve needed DLLs.