File not found errors when building Sonarr's backend with commandline

Sonarr version (exact version): forked the latest develop branch (I’m building as a contributor)
OS: Debian GNU/Linux 12 (bookworm). I’m specifically using Github Codespaces.
Description of issue:

I’m following the contributor build instructions on this wiki page (the “Command line” section) :

I start the frontend:

yarn install
yarn start

I start the backend (using commandline not Visual Studio):

dotnet clean src/Sonarr.sln -c Debug
dotnet msbuild -restore src/Sonarr.sln -p:Configuration=Debug -p:Platform=Posix -t:PublishAllRids

I run the following file:

This file does seem to start the backend server, but I see the following error in the Terminal:

[Error] BrowserService: Couldn't open default browser to http://localhost:8989 

[v10.0.0.2957] System.ComponentModel.Win32Exception (2): An error occurred trying to start process 'http://localhost:8989' with working directory '/workspaces/Sonarr/_output/net6.0/linux-x64/publish'. No such file or directory
   at System.Diagnostics.Process.ForkAndExecProcess(ProcessStartInfo startInfo, String resolvedFilename, String[] argv, String[] envp, String cwd, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec)
   at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at NzbDrone.Common.Processes.ProcessProvider.OpenDefaultBrowser(String url) in ./Sonarr.Common/Processes/ProcessProvider.cs:line 105
   at NzbDrone.Host.BrowserService.LaunchWebUI() in ./Sonarr.Host/BrowserService.cs:line 37

When I go to localhost:8989, I get the following error message:

  "type": "",
  "title": "Not Found",
  "status": 404,
  "traceId": "00-8d2326d161fb8cee537aeee14fe6c210-b021ee4f59675154-00"

Thank you for your help.

Does the x64 build work properly without that error?
Looks like the front end is missing, usually it’s in _output/UI, which when debugging in VS is where things run from, but since you compiled with dotnet directly it appears they’re not in the same location.