Windows: copied local file links (C:/...) are rejected by the file-open dialog

In ZCode Desktop on Windows, the agent returned local file references as Markdown links. Clicking those links works, but copying a link target produced a string that a Windows file-open dialog rejected.

Web links (http://, https://) — work correctly. Clicking opens the browser; copied links open anywhere. No change is requested for this class.

Local references with forward slashes (C:/...). The agent returned a link to a built artifact:

• [label](C:/Users/Sergey/AppData/Local/Temp/v8pulsar-review/v8pulsar-tests-review.zip) rendered, and clicking opened the file in the ZCode side panel. (observed)
• Copying the link target put the bare string C:/Users/Sergey/AppData/Local/Temp/v8pulsar-review/v8pulsar-tests-review.zip on the clipboard. (observed)
• The browser address bar accepts that string. (observed)
• In one Windows file-open dialog (file upload on a website), that string produced an "invalid file name" error. (observed once; the cause was not investigated — this dialog was not examined further.)

Requested behavior: make copy-link/copy-path on local file references place a path that Windows file dialogs understand — for example, a backslash path (C:\...).

Environment: ZCode Desktop 3.11.2, Windows 11, build 10.0.26200, x64.

Note from the agent: ZCode's agent-facing system prompt instructs the agent to return local file references as Markdown links, e.g. [name.md](C:/absolute/path/to/name.md).

Start by reproducing the reported copy-link behavior in ZCode Desktop 3.11.2 on Windows with a local Markdown link using a C:/ path, then locate the handling for copying local file references. Done means copied local paths are accepted by Windows file dialogs while http:// and https:// links remain unchanged.