Generate JavaScript-free version of the HTML report

### 🤔 What's the problem you're trying to solve?

I'm trying to migrate to an environment where the Cucumber report will be rendered inside a sandboxed iframe, with strict security settings. This means the JavaScript in the report is prevented from running, and the report fails to render. The current workaround is to download the report and open it locally.

### ✨ What's your proposed solution?

I believe there are three main JavaScript features in the report:

1. Expandable/collapsible sections for each feature (and around attached images, I believe)
2. Filtering the displayed features/scenarios by status (passed/failed/skipped)
3. Filtering the displayed features/scenarios by full text search

All are appreciated, but I could sacrifice 2 & 3. I think expandable/collapsible sections are critical to maintain readability, but I also think they could be replaced by modern HTML details/summary tags. I don't know if this would require forking the html-formatter or if it could be a configuration option. If (2) is possible to do without JavaScript that would also be useful. I have little hope for (3), but the browser has a find-in-page feature too.

Perhaps if the default rendering used HTML details/summary tags instead of JavaScript, the other features would just degrade to non-functional in a no-JavaScript environment, and there'd be no need to fork/configure the html-formatter.

### ⛏ Have you considered any alternatives or workarounds?

I could produce a custom report in plain HTML, but my preference has been to encourage people to embrace the standard Cucumber report rather than roll their own, and this is starting to look like it may bite me if the standard report no longer works in our strict security environment. Telling users to download the report when it's blank is an option, but not a great experience.

### 📚 Any additional context?

_No response_

The issue concerns the generated HTML report's JavaScript features: expandable sections, status filtering, and text search. First determine how the report currently renders those features and whether HTML details/summary can replace expansion. Done would mean the report renders in a JavaScript-blocked sandbox, with at least readable expandable sections; the scope of filtering remains undecided.

Written by the indexing model from the issue text.