Airlock logging setup is decided by a substring match on formatted JSON

[GordonBeeming]

SetupLogsDirectory and the rules-file handling in AirlockRunner.cs decide whether logging is on by substring-matching the raw file:

// AirlockRunner.cs:298 and :426
if (content.Contains("\"enable_logging\": true") || content.Contains("\"mode\": \"monitor\""))

That match includes the space after the colon. network.json is a file people hand-edit, so writing it as "enable_logging":true, or with a line break, or with the key quoted differently, is entirely reasonable and leaves the config semantically identical. When that happens the check fails, the logs directory is never created, and its .gitignore never gets written. Logging looks enabled in the config and silently produces nothing.

It also can't tell a real setting from a coincidence: the same string appearing inside a comment, or in an allowed_paths entry, matches just as well.

The config is already parsed into NetworkConfig elsewhere in the same file, so the fix is to read EnableLogging and Mode off the deserialized object rather than pattern-matching the bytes.

Worth a test that writes "enable_logging":true with no space and asserts the logs directory appears.