vmui: render unsafe markdown links as text in logs view

[func25]

Only explicit http:// and https:// links are rendered as clickable links. Other markdown links and images are rendered as plain text.

Follow up aadc99b

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[Loori-R]

Updated the markdown link rendering changes:

• moved link-related helpers into a separate markedLinks utility
• kept only explicit inline http/https markdown links clickable
• rendered reference-style links and reference definitions as plain text
• rejected URL control characters, including C1 controls
• added tests for XSS in link text, reference-style links, preserved definitions, and control-character URLs

[valyala]

Why char codes bigger than 0x9f are considered as valid codes?

[Loori-R]

Because this check is specifically about rejecting control characters, not rejecting non-ASCII characters in general.

0x00–0x20 and 0x7f are ASCII control/whitespace characters. 0x80–0x9f is the C1 control range. These characters are not useful in URLs and can create parsing/escaping ambiguities.

Characters above 0x9f are regular Unicode code points, not control characters. They can be valid in URLs after new URL() parsing/normalization, for example in IDN domains or non-ASCII paths.

So > 0x9f is intentionally allowed here. Final URL validation is still done by new URL(href) and the explicit http/https protocol check.

[func25]

@Loori-R there are some invisible/bidi code points above 0x9f, wdyt about using:

const forbiddenURLCharsRegex = /[\p{Cc}\p{Cf}\p{Zs}\p{Zl}\p{Zp}\p{Default_Ignorable_Code_Point}]/u;
forbiddenURLCharsRegex.test(value);

Just got idea from this

[Loori-R]

This is stricter, but it makes sense for clickable URLs in logs.