fix(message): recognize uppercase URL schemes

[adityaalifn]

Summary

Uppercase or mixed-case URL schemes in message text (e.g. HTTPS://example.com, Https://example.com, FTP://example.com) were getting a second https:// scheme glued on, producing a broken href like https://HTTPS://example.com. The link rendered but pointed nowhere.

The bug

In MessageTextComponent.wrapLinksWithAnchorTag, the message text is scanned with a case-insensitive URL regex (urlRegexp is built with the i flag, so it correctly matches HTTPS://...). But the follow-up check that decides whether to prepend https:// used case-sensitive startsWith:

if (
  !href.startsWith('http') &&
  !href.startsWith('ftp') &&
  !href.startsWith('file')
) {
  href = `https://${match}`;
}

'HTTPS://example.com'.startsWith('http') is false, so an already-absolute URL got https:// prepended, yielding href="https://HTTPS://example.com".

Reproduction

Render a message whose text contains HTTPS://example.com. The rendered anchor's href becomes https://HTTPS://example.com instead of HTTPS://example.com.

Fix

Replace the case-sensitive startsWith checks with a single case-insensitive scheme test that requires the :// separator:

if (!/^(?:https?|ftp|file):\/\//i.test(href)) {
  href = `https://${match}`;
}

Now absolute URLs with any-case schemes are left untouched, while scheme-less inputs like example.com still get https:// prepended. The matching urlRegexp already had the i flag, so no regex change was needed.

Tests

Added a regression test in message-text.component.spec.ts asserting that uppercase/mixed-case absolute URLs (HTTPS://, Https://, FTP://) are not double-prefixed, and that scheme-less input (example.com) still gets https://. The full message-text spec passes (12/12) under the project's Karma/Jasmine runner.