fix(cmd): include backslash in path detection for @ file references

[hsusul]

Observed Behavior

When passing an @ file reference containing backslash path separators (such as @subfolder\\unreadablefile or Windows paths without a file extension) that fails to open, embedFilesValue in pkg/cmd/flagoptions.go did not recognize \\ as a path separator. As a result, probablyFile / expectsFile evaluated to false, silently falling back to treating the unreadable file path as a raw string literal ("@subfolder\\\\unreadablefile") instead of surfacing a file read error.

Root Cause

probablyFile and expectsFile checks in pkg/cmd/flagoptions.go (lines 237 and 265) checked for . and / (strings.Contains(filename, ".") || strings.Contains(filename, "/")), but omitted \\ (strings.Contains(filename, "\\\\")).

Implementation

Updated path detection in embedFilesValue (pkg/cmd/flagoptions.go) to also check for \\ (strings.Contains(filename, "\\\\")), ensuring paths using backslashes are recognized as file references when handling unreadable file errors.

Regression Coverage

Added unit test case "non-existent file with backslash path @ prefix (error)" in pkg/cmd/flagoptions_test.go to assert that unreadable backslash path references properly return a file reading error instead of falling back to a raw string literal.

Exact Validation Commands & Results

• go test ./pkg/cmd -run TestEmbedFiles -> Passed
• go test ./internal/... -> Passed
• go vet ./internal/... ./pkg/... -> Passed (clean)
• git diff --check -> Passed (clean)

Limitations or Untested Platforms

None.

Unrelated Changes

No unrelated changes were included.