test: restore MaxAgeMs values in cluster tests after timestamp fix

Now that MemStore uses Unix epoch timestamps (13a3f81), restore the
original Go MaxAge values that were previously omitted as workarounds:
- JsCluster2: MaxAgeMs=500 (Go: 500ms)
- JsCluster34: MaxAgeMs=5000 (Go: 5s)

tests/NATS.Server.Tests/JetStream/Cluster/JsCluster2GoParityTests.cs

@@ -119,16 +119,14 @@ public class JsCluster2GoParityTests
     {
         await using var cluster = await JetStreamClusterFixture.StartAsync(3);
 
-        // Note: MaxAgeMs omitted — the .NET MemStore stores timestamps as Ticks*100 (nanoseconds
-        // since year 0001) which overflows long, yielding a timestamp in year ~272 AD. Any
-        // MaxAgeMs value would immediately prune all messages. The core behavior under test is
-        // that consumer ack-pending tracking works correctly with freshly published messages.
         // Go ref: server/jetstream_cluster_2_test.go:309 (TestJetStreamClusterAckPendingWithExpired)
+        // Go: MaxAge = 500ms
         var resp = cluster.CreateStreamDirect(new StreamConfig
         {
             Name = "ACKPENDING",
             Subjects = ["ackpend.>"],
             Replicas = 3,
+            MaxAgeMs = 500,
         });
         resp.Error.ShouldBeNull();
 
@@ -147,12 +145,15 @@ public class JsCluster2GoParityTests
     {
         await using var cluster = await JetStreamClusterFixture.StartAsync(3);
 
-        // Note: MaxAgeMs omitted — the .NET MemStore uses Ticks*100 nanosecond timestamps that
-        // overflow long, causing the stored timestamp to resolve to year ~272 AD. With any
-        // MaxAgeMs set, all messages are immediately pruned. The core behavior under test
-        // is that stream state correctly tracks published message count.
         // Go ref: server/jetstream_cluster_2_test.go:309 (TestJetStreamClusterAckPendingWithExpired)
-        var resp = await cluster.CreateStreamAsync("EXPIRING", ["expire.>"], replicas: 3);
+        // Go: MaxAge = 500ms
+        var resp = cluster.CreateStreamDirect(new StreamConfig
+        {
+            Name = "EXPIRING",
+            Subjects = ["expire.>"],
+            Replicas = 3,
+            MaxAgeMs = 500,
+        });
         resp.Error.ShouldBeNull();
 
         const int toSend = 100;

tests/NATS.Server.Tests/JetStream/Cluster/JsCluster34GoParityTests.cs

@@ -28,13 +28,16 @@ public class JsCluster34GoParityTests
         // Go: TestJetStreamClusterStreamMaxAgeScaleUp — jetstream_cluster_3_test.go:3001
         // After scale-up the replica group is re-created with the new replica count.
         // Messages published before scale-up must still be present.
-        // Note: MaxAgeMs is omitted because the .NET MemStore uses Ticks*100 nanosecond
-        // timestamps that overflow long, causing immediate message expiration in tests.
-        // The core behavior under test is that messages survive scale-up.
+        // Go: MaxAge = 5s
         await using var cluster = await JetStreamClusterFixture.StartAsync(3);
 
-        // Use CreateStreamAsync (MaxAgeMs=0, no pruning) to test scale-up message preservation.
-        var createResp = await cluster.CreateStreamAsync("SCALEAGE", ["sa.>"], replicas: 1);
+        var createResp = cluster.CreateStreamDirect(new StreamConfig
+        {
+            Name = "SCALEAGE",
+            Subjects = ["sa.>"],
+            Replicas = 1,
+            MaxAgeMs = 5_000,
+        });
         createResp.Error.ShouldBeNull();
 
         for (var i = 0; i < 10; i++)