[Repo Assist] perf: HtmlNode.serialize avoids per-indent string alloc; isVoidElement as module-level constant

[github-actions]

🤖 This is an automated pull request from Repo Assist, an AI assistant for this repository.

Summary

Three focused performance improvements to HtmlNode / HtmlDocument serialization.

Changes

1. isVoidElement as a module-level constant

Before: HtmlNode.ToString() reconstructed a Set<string> of 16 void element names on every call, then wrapped it in a closure.

After: The set (and the isVoidElement predicate) are computed once at module initialisation time, stored in a [<AutoOpen>] module private HtmlNodeHelpers. This eliminates one Set.ofArray + 16-element insertion per ToString() call.

2. newLine uses StringBuilder.Append(char, int) directly

Before:

let newLine plus =
    sb.AppendLine() |> ignore
    String(' ', indentation + plus) |> append   // allocates a temporary string

After:

let newLine plus =
    sb.AppendLine() |> ignore
    sb.Append(' ', indentation + plus) |> ignore  // writes spaces directly, no string alloc

StringBuilder.Append(char, repeatCount) writes the character into the internal buffer directly without creating an intermediate string. Every pretty-printed element that starts a new line previously paid one allocation; now it pays zero.

3. HtmlDocument.ToString() uses a single StringBuilder

Before:

+ (elements |> List.map (fun x -> x.ToString()) |> String.Concat)
```
Each `HtmlNode.ToString()` created its own `StringBuilder`, serialised to it, and returned a `string`. The outer code then built an `FSharpList` of those strings before concatenating.

**After**: A single `StringBuilder` is created; `element.ToString()` is appended directly. The intermediate list allocation is gone.

## Test Status

```
Passed! - Failed: 0, Passed: 2980, Skipped: 0, Total: 2980 (net8.0, -p:NuGetAudit=false)

Pre-existing infrastructure warning (OpenTelemetry.Api 1.15.0 vulnerability via NuGet audit) suppressed with -p:NuGetAudit=false; unrelated to this change, tracked in PR #1762.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@96b9d4c39aa22359c0b38265927eadb31dcf4e2a

[github-actions]

Commit pushed: 7f959f0

Generated by 🌈 Repo Assist, see workflow run. Learn more.

[dsyme]

/repo-assist Work out why CI is failing on windows sometimes and create a separate PR for the fix

[github-actions]

✓ Repo Assist completed successfully, see workflow run.

[github-actions]

Pull request created: #1774

Generated by 🌈 Repo Assist, see workflow run. Learn more.

[github-actions]

🤖 Repo Assist here — investigating the Windows CI failures.

Root cause found. In tests/FSharp.Data.Core.Tests/XmlExtensions.fs, the startXmlHttpLocalServer() helper selects a port using Random.Next + GetActiveTcpListeners(). On Windows, Hyper-V and Docker reserve port ranges that are not returned by GetActiveTcpListeners() — so the code picks a "free" port that's actually in an excluded range, causing Kestrel to fail at bind time with:

SocketException (10013): An attempt was made to access a socket in a way forbidden by its access permissions.

The Http.fs test helper already uses the correct TcpListener(0) approach (ask the OS for a free port, guaranteed not excluded).

Fix submitted on branch repo-assist/fix-windows-ci-port-binding-2026-05-08:

• Replace GetActiveTcpListeners random scan with TcpListener(0) (same as Http.fs)
• Use app.StartAsync() instead of app.RunAsync() + Thread.Sleep(100), so server readiness is deterministic rather than a timed guess

All 13 XmlExtensions tests pass locally after the fix.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@fc4ab36dedc44e2a1cdc195cecce262f06c81230