bench: add RenderToString suite covering the string-returning API

[rexm]

Summary

Adds a RenderToString benchmark suite covering the string-returning template API — the most common way the library is consumed in practice.

Why

All existing Render* suites invoke templates against TextWriter.Null. That measures path-resolution and iteration overhead well, but a no-op writer hides the entire output side of rendering: HTML encoding and the actual StringBuilder-backed writes. During benchmarking of output-path optimizations, TextWriter.Null produced misleading results in both directions — it understated real-world wins (per-char writes are nearly free on a null writer) and manufactured regressions that don't exist for real writers (TextWriter's base span implementation rents/copies via ArrayPool, which StringWriter/StreamWriter never hit).

What it measures

• A 50-item {{#each}} list template rendered through HandlebarsTemplate<object, object> (i.e. template(data) returning a string), which exercises the pooled ReusableStringWriter path.
• Two content cases:
  • clean — values contain nothing that needs HTML escaping (typical data);
  • html — values are dense with characters that must be escaped (worst case for encoder fast paths).

Runtime cost: ~1 minute per full suite run (2 cases × ~30s), well within the benchmark time budget.

Baseline numbers (master, Apple M4, .NET 10)

Method	Content	Mean	Error	StdDev	Gen0	Gen1	Allocated
Render	clean	13.95 us	0.108 us	0.095 us	3.9215	0.2289	32.09 KB
Render	html	14.75 us	0.118 us	0.110 us	4.3030	0.2594	35.31 KB

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud