docs: add blog post evaluating GHC WASM for browser-based execution and supporting architecture diagrams

[Arman-op]

Summary

This PR adds a new DataHaskell blog post documenting an evaluation of the GHC/WebAssembly (GHC/Wasm) toolchain for browser-based Haskell execution, written as part of my GSoC 2026 project with Haskell.org.

The article is a system-level walkthrough of the GHC in Browser project, explaining how GHC is compiled to WebAssembly and executed entirely within a browser environment. The investigation was conducted to better understand the feasibility of integrating a GHC/Wasm backend into xeus-haskell for browser-based notebook environments such as JupyterLite.

What's Covered

• How GHC is compiled to WebAssembly and executed in the browser
• The role of WASI in providing filesystem and I/O capabilities within a browser sandbox
• Architecture overview: UI layer, JavaScript runtime, GHC Wasm runtime, and browser platform
• Execution flow from source code to compiled result
• Virtual filesystem design for in-browser package and library access
• Runtime architecture and module interactions
• Relevance and implications for future xeus-haskell / JupyterLite integration

Changes

New Blog Post

• _posts/2026-06-20-evaluating-ghc-wasm-for-browser-based-haskell-execution.md

New Diagrams

Added the following supporting diagrams under /images/:

1. Understanding GHC Browser Diagram
2. Traditional vs Native Diagram
3. Native Diagram
4. Architecture Diagram
5. WebAssembly Diagram
6. WASI Working Diagram
7. Execution Flow Diagram
8. Working Module Diagram

These diagrams are used throughout the article to illustrate the architecture, execution model, and browser runtime workflow.

[daikonradish]

hey, couple thoughts:

1. Header hierarchy is broken. Most of your section headers aren't actually headings, they're just bold paragraphs (# **1.2 Architectural Questions** is a real heading because it is prefixed by #, but the rest of the bulleted numbers are just bolded text). Could you please make every section header a real markdown heading, and use levels consistently? — top-level sections (1, 2, 3...) as ##, subsections (2.1, 2.2...) as ###. Reserve a single # for the page title (which should be the highest element on the page)
2. You skipped section 2.2.
3. Thematically, there are too many things going on in this blog post. What is it exactly you want to say? Is it GHC in the browser? OR are you evaluating GHC WASM? I would say, stick to one point and then elaborate it. If it's both, make the hierarchy clear. But I would say, you had a project (GHC WASM) and it has a clear purpose (running GHC in browser).
4. the "key takeaways" section is a bit of an afterthought, when it should be the forethought. Begin with the end in mind -- what exactly do you want us to takeaway? What problems did you most valuably solve? What learnings did you valuably make? What's the next steps for the motivated reader?