Restore the standard OpenSearch heap for million-record sessions

The full three-node Linux load exhausted the configured 512 MiB JVM heap near 900k documents, returning 429 circuit_breaking_exception after GC failed to reduce heap usage. Use the pinned server default of 1 GiB per node within the same recorded host envelope.

Validation: full Debug solution build -warnaserror with 0 warnings/errors; full format verification and governance passed; real one/three-node million-record controls passed; JVM API confirmed 1 GiB on all three nodes and actual containers/volumes were removed. Keep batch 500, sixteen clients, durability, oracles and operation/workload deadlines. Full Linux qualification remains required.

Author: KSemenenko

build/KeyLoad.LoadTests.AppHost/Configuration/BenchmarkDeploymentOptions.cs

@@ -8,7 +8,7 @@ internal sealed record BenchmarkDeploymentOptions
     private const int DefaultNeo4jInitialHeap = 256;
     private const int DefaultNeo4jMaximumHeap = 512;
     private const int DefaultNeo4jPageCache = 256;
-    private const int DefaultOpenSearchHeap = 512;
+    private const int DefaultOpenSearchHeap = 1024;
     private const int DefaultPostgresSlotRetention = 512;
     private const int DefaultDocumentPostgresConnections = 512;
     private const int MinimumDocumentPostgresConnections = 512;

docs/Features/BenchmarkComparisons/SessionExecution.md

@@ -182,6 +182,12 @@ files, KeyLoad included. The manual Release workflow alone publishes the KeyLoad
 server image with SDK `PublishContainer`.
 
 The Redis topology probe removes its transient key before document readback.
+OpenSearch uses a 1 GiB JVM heap per node, matching the pinned server's default.
+This setting applies to both topologies within the recorded host
+resource envelope; the 500-document request bound, sixteen clients, persisted-copy
+acknowledgements and full workload remain unchanged. OpenSearch documents its
+[default heap and memory sizing](https://docs.opensearch.org/latest/install-and-configure/install-opensearch/index/).
+
 The HelixDB document target owns its HTTP clients within one dedicated Aspire
 session. That session owns the private server and its anonymous writable volume.
 After the complete workload and final-state oracle, the target closes its clients;