Live Preview can generate malformed URLs for absolute links and workspace paths

Bug

Live Preview can generate malformed preview URLs in two related cases:

1. Absolute HTTP(S) URLs can be prefixed with the preview host, producing URLs such as http://127.0.0.1:3000/http://example.test/page.html and, depending on the caller-provided value, http://http://....
2. Workspace-relative paths can be returned without a leading slash when the workspace root already ends with a path separator, producing a URL with the path joined directly after the port, e.g. http://127.0.0.1:3000index.html.

Expected behavior

• Absolute http:// and https:// URLs should be preserved as absolute URLs.
• Preview paths served from the local Live Preview host should include / after the port.

Actual behavior

• Absolute HTTP(S) URLs can be treated as local preview paths and receive another host/protocol prefix.
• In trailing-separator workspace cases, the path can be appended immediately after the port.

Environment

• Extension: Live Preview 0.4.18 local build, also observed while testing 0.4.19 install behavior
• OS: Windows
• Workspace type involved in repro: local/network workspace path where the resolved workspace root can include a trailing separator

Proposed fix

I have a small fix and regression tests ready in branch dknn:codex/fix-live-preview-url-normalization:

• preserve absolute http:// and https:// URL inputs in WebviewComm.constructAddress
• ensure Connection.getFileRelativeToWorkspace returns a leading slash for workspace-relative paths

Start by inspecting WebviewComm.constructAddress and Connection.getFileRelativeToWorkspace, focusing on absolute HTTP(S) inputs and workspace roots with trailing separators. Reproduce both malformed URL cases, then run or extend the regression tests mentioned in the issue. Done means absolute URLs remain unchanged and local preview paths always have a slash after the port.