fix: Restore tar archive write performance regressed by padding trim

Author: HofmeisterAn

src/Testcontainers/Images/DockerfileArchive.cs

@@ -192,7 +192,7 @@ public async Task<string> Tar(CancellationToken ct = default)
 
       using (var tarOutputFileStream = new FileStream(dockerfileArchiveFilePath, FileMode.Create, FileAccess.Write))
       {
-        using (var tarOutputStream = new TarOutputStream(tarOutputFileStream, TarArchiveDefaults.TarBlockFactor, Encoding.Default))
+        using (var tarOutputStream = new TarOutputStream(tarOutputFileStream, Encoding.Default))
         {
           tarOutputStream.IsStreamOwner = false;
 

src/Testcontainers/TarArchiveDefaults.cs

@@ -9,6 +9,13 @@ internal static class TarArchiveDefaults
     // blocks while the HTTP sender is still flushing the padding, causing EPIPE
     // (HTTP 500 "broken pipe"). See:
     // https://github.com/testcontainers/testcontainers-dotnet/issues/1683.
+    //
+    // This only applies to archives we stream to the daemon over a pipe (resource
+    // mappings via a MemoryStream), where the surplus padding is both unnecessary
+    // and harmful. Do NOT reuse it for the Dockerfile build context, which is
+    // written to a FileStream on disk: a 512 B record forces a write and flush per
+    // block and regresses image builds. That path keeps SharpZipLib's default block
+    // factor on purpose.
     internal const int TarBlockFactor = 1;
   }
 }