.Net: Harden FileIOPlugin/WebFileDownloadPlugin UNC path separator validation

[rogerbarreto]

Summary

FileIOPlugin.IsFilePathAllowed in dotnet/src/Plugins/Plugins.Core/FileIOPlugin.cs guards against UNC paths only when they use the backslash form (\\server\share). On Windows, the forward-slash and mixed-separator forms (//server/share, /\server/share, \/server/share) are canonicalized by .NET to the same UNC path, so they are not caught by the current check. In addition, the method calls File.Exists(path) before the allowed-folders decision is returned, so a path pointing at a remote host can cause a network round-trip before the allow-list rejects it.

dotnet/src/Plugins/Plugins.Web/WebFileDownloadPlugin.cs contains an identical IsFilePathAllowed with the same backslash-only check.

Affected area

• .NET: dotnet/src/Plugins/Plugins.Core/FileIOPlugin.cs
• .NET: dotnet/src/Plugins/Plugins.Web/WebFileDownloadPlugin.cs
• Python: not affected (no equivalent file-IO core plugin exists).

Expected behavior

UNC-style paths should be rejected consistently regardless of the separator style used (backslash, forward-slash, or mixed), matching the existing backslash-form rejection.

Plan

• Harden the path check in both plugins so that any path beginning with two directory-separator characters (in any combination of / and \) is rejected.
• Add unit tests covering the forward-slash form for both plugins (the backslash form is already covered).

[jstar0]

I can take this. I'll keep the change to the two .NET plugins named in the issue: reject any two-character UNC prefix across / and \ before canonicalization or filesystem probes, and add focused read, write, and download regressions for forward-slash and mixed-separator forms without changing non-UNC path behavior.