SQL Server restore not linking files in localDb

Question

My dev team uses local db (15.0.4153 installed by Visual Studio 2022) to house our development databases. One of our environment SQL Servers is running SQL Server 2014 (12.0.6329.1) on Windows Server 2019.

The drives on the 2019 server are not the same as those on the dev machines, so we always go to files and relocate them to the correct local drive. Everything works and looks good when the restore takes place, but once we restart the machine the restored database is in Recovery Pending mode. This seems to have started after we upgraded the environment server from Windows 2012 R2 to Windows 2019.

The strangest part is if I restore to a local instance of SQL Server 2022 Dev Edition 16.0.10000.6 the exact same way, everything works fine even after restarting the machine.

The problem appears to be that the files aren't getting linked to the database appropriately, as when I drop the database that is in recovery pending the .mdf file is deleted, but the .ldf file is not deleted.

Edit 7/18/2023: The following is the sql being used to restore the db:

USE [master];
RESTORE DATABASE [MyDb]
FROM DISK = N'C:\Database\Backups\my_backup.bak'
WITH FILE = 1,
     MOVE N'MyDb'
     TO N'C:\Database\Data\MyDb.mdf',
     MOVE N'MyDb_log'
     TO N'C:\Database\Data\MyDb_log.ldf',
     NOUNLOAD,
     STATS = 5;

Edit 7/19/2023 I ran the following command and got a bit of a clue potentially ALTER DATABASE MyDb SET ONLINE, I get the following errors:

Msg 1853, Level 16, State 1, Line 7
The logical database file 'MyDb_log' cannot be found. Specify the full path for the file.
Msg 5181, Level 16, State 5, Line 7
Could not restart database "MyDb". Reverting to the previous status.
Msg 5069, Level 16, State 1, Line 7
ALTER DATABASE statement failed.

When I run the following command however I find that the file does exist on the disk, so I'm a little at a loss as to why Sql Server cannot access it.

SELECT 
  name as 'Logical Name', 
  physical_name as 'File Location'
FROM sys.master_files;