Handle empty response file name in command line parser

[LeSingh1]

Fixes #3758.

Running tsgo with a bare @ argument crashes with a panic in the vfs layer:

panic: vfs: path "" is not absolute

The crash comes from parseStrings taking the suffix after @ (which is empty) and passing it to parseResponseFile, which then asks the vfs to read the empty path. RootLength in internal/vfs/internal panics on a non-absolute path, so the process exits before any diagnostic is reported.

This change short-circuits at the top of parseResponseFile when the file name is empty and reports the existing Cannot_read_file_0 diagnostic instead, which is what users would get for any other unreadable response file.

The change is four lines in internal/tsoptions/commandlineparser.go. I do not have a Go toolchain on this machine, so I have not run go test ./... or hereby test locally. Happy to add a baseline test once a maintainer confirms the approach, or if pointed at the right scenario harness.

[Copilot]

Pull request overview

Fixes a CLI crash in the tsgo command-line parser when a response file argument is provided as a bare @ by short-circuiting response-file parsing and emitting Cannot_read_file_0 instead of reaching the VFS layer panic.

Changes:

• Add an early check in parseResponseFile for an empty response file name and report Cannot_read_file_0 rather than calling into vfs.FS.ReadFile.

Comments suppressed due to low confidence (1)

internal/tsoptions/commandlineparser.go:169

• Please add a regression test for the @-only argument so we verify this path reports Cannot_read_file_0 instead of panicking (there are existing command line parser tests in internal/tsoptions/commandlineparser_test.go). This repo’s guidelines expect at least one minimal test case for bug fixes.

	if fileName == "" {
		p.errors = append(p.errors, ast.NewCompilerDiagnostic(diagnostics.Cannot_read_file_0, fileName))
		return
	}

[jakebailey]

The right fix is in #3859; the issue is wider than empty strings