fix: eliminate XSS vulnerability in CodeBlock component

[KJ7LNW]

This PR addresses a cross-site scripting (XSS) vulnerability in the CodeBlock component identified by CodeQL.

Context

The CodeBlock component was using dangerouslySetInnerHTML to render syntax-highlighted code from Shiki, which posed a security risk.

Implementation

The fix replaces dangerouslySetInnerHTML with a safer approach using codeToHast and direct React element rendering:

1. Added hast-util-to-jsx-runtime dependency
2. Modified the syntax highlighting logic to use codeToHast instead of codeToHtml
3. Updated the MemoizedCodeContent component to render React elements directly
4. Changed the state type from string to React.ReactNode

Security Considerations

• Eliminates potential for HTML injection attacks
• Maintains all syntax highlighting capabilities
• Preserves exact visual output

Performance Considerations

• Direct React element creation is more efficient than HTML parsing
• No browser HTML parsing overhead
• Memoization pattern preserved for optimal rendering

How to Test

1. Open any code sample in the chat
2. Verify syntax highlighting works correctly
3. Test word wrap and collapse functionality
4. Ensure copy code functionality works

This issue was discovered as part of security review #3785.

Fixes #5156

---

Important

Fixes XSS vulnerability in CodeBlock by replacing dangerouslySetInnerHTML with hast-util-to-jsx-runtime for safer rendering.

• Security Fix:
  • Replaces dangerouslySetInnerHTML with hast-util-to-jsx-runtime in CodeBlock.tsx to prevent XSS.
  • Updates highlightedCode state type from string to React.ReactNode.
• Dependencies:
  • Adds hast-util-to-jsx-runtime to package.json.
• Rendering:
  • Uses codeToHast for syntax highlighting instead of codeToHtml.
  • MemoizedCodeContent now renders React elements directly.

^{This description was created by for e1fc1aa. You can customize this summary. It will automatically update as commits are pushed.}

[daniel-lxs]

Thank you @KJ7LNW!

We also have other instances of dangerouslySetInnerHTML that we can remove using a similar approach to this PR.

LGTM