[Feature]: Decide on, and if chosen, move to Blazor WebAssembly hosting  #64

What type of issue is this?

• Bug report
• Feature request

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of the reqifviewer
• I have searched open and closed issues to ensure it has not already been reported

Description

With WebAssembly the file never leaves the user's browser, the server holds no per-user state, a reload can restore the document from browser storage, and phase 2 edits survive a dropped connection. The viewer started as WebAssembly and moved to server-side hosting in 2024 because XML parsing was too slow in the browser (#35), so this needs to be re-measured on .NET 10 before deciding.

Acceptance criteria

• Spike: load the largest sample file in WebAssembly and measure download size, load and parse time, and compare with server-side parsing. Implement server-side hosting next to webassembly hosting #35 moved the viewer from WebAssembly to the server in 2024 because parsing was too slow in the browser; check whether .NET 10 (including AOT compilation) changes that.
• If adopted: files are processed in the browser only; the home page says so; the server only serves static files (the Docker image gets simpler).

Steps to Reproduce

Load requirements-and-objects.reqifz or ProR_Traceability-Template-v1.0.reqif (reqifviewer.Tests/TestData) and look at the pages mentioned above.

System Configuration

• reqifviewer version: 6.1.0 (development, with [Refactor] Blazor Blueprint app shell and Blazor Web App hosting #56)
• Environment (Operating system, version and so on): Windows 11, Chrome
• .NET Framework version: .NET 10
• Additional information: Plan item F-08 of the viewer improvement plan. Size: L.