Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/Testcontainers/Logging.cs (1)

206-210: ⚡ Quick win

Restore the IsEnabled check to avoid unnecessary allocations when logging is disabled.

The removal of the IsEnabled(LogLevel.Information) guard means string.Join(" ", command) now executes unconditionally, even when Information logging is disabled. This creates unnecessary string allocations in production scenarios where this log level is typically off. Since DockerContainerOperations.ExecAsync calls this wrapper for every container exec operation, the impact could be significant on hot paths.

Line 264 demonstrates the established pattern of guarding expensive operations with IsEnabled checks.

⚡ Proposed fix to restore the guard

 public static void ExecuteCommandInDockerContainer(this ILogger logger, string id, IEnumerable<string> command)
 {
+  if (!logger.IsEnabled(LogLevel.Information))
+  {
+    return;
+  }
+
   var commandLine = string.Join(" ", command);
   ExecuteCommandInDockerContainerCore(logger, commandLine, new TruncatedId(id));
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/Testcontainers/Logging.cs` around lines 206 - 210, Restore the logging
guard in ExecuteCommandInDockerContainer to avoid allocating the joined command
string when Information logging is disabled: wrap the string.Join(" ", command)
and the call to ExecuteCommandInDockerContainerCore in an if
(logger.IsEnabled(LogLevel.Information)) { ... } block (using the same pattern
as seen at other sites), so only when logger.IsEnabled(LogLevel.Information) is
true you construct commandLine and call
ExecuteCommandInDockerContainerCore(logger, commandLine, new TruncatedId(id));
leave TruncatedId and ExecuteCommandInDockerContainerCore unchanged.