Fix invisible script execution on Windows #264

This commit addresses an issue in the privacy.sexy desktop application
where scripts executed as administrator on Windows were running in the
background. This was observed in environments like Windows Pro VMs on
Azure, where operations typically run with administrative privileges.

Previously, the application used the `"$path"` shell command to execute
scripts. This mechanism failed to activate the logic for requesting
admin privileges if the app itself was running as an administrator.
To resolve this, the script execution process has been modified to
explicitly ask for administrator privileges using the `VerbAs` method.
This ensures that the script always runs in a new `cmd.exe` window,
enhancing visibility and user interaction.

Other supporting changes:

- Rename the generated script file from `run-{timestamp}-{extension}` er
  to `{timestamp}-privacy-script-{extension}` for clearer identification
  and better file sorting.
- Refactor `ScriptFileCreator` to parameterize file extension and
  script name.
- Rename `OsTimestampedFilenameGenerator` to
  `TimestampedFilenameGenerator` to better reflect its new and more
  scoped functionality after refactoring mentioned abvoe.
- Remove `setAppName()` due to ineffective behavior in Windows.
- Update `SECURITY.md` to highlight that the app doesn't require admin
  rights for standard operations.
- Add `.editorconfig` settings for PowerShell scripts.
- Add a integration test for script execution logic. Improve environment
  detection for more reliable test execution.
- Disable application logging during unit/integration tests to keep test
  outputs clean and focused.

src/presentation/bootstrapping/ClientLoggerFactory.ts

@@ -13,15 +13,41 @@ export class ClientLoggerFactory implements LoggerFactory {
 
   protected constructor(
     environment: RuntimeEnvironment = CurrentEnvironment,
+    windowAccessor: WindowAccessor = () => globalThis.window,
+    noopLoggerFactory: LoggerCreationFunction = () => new NoopLogger(),
+    windowInjectedLoggerFactory: LoggerCreationFunction = () => new WindowInjectedLogger(),
+    consoleLoggerFactory: LoggerCreationFunction = () => new ConsoleLogger(),
   ) {
+    if (isUnitOrIntegrationTests(environment, windowAccessor)) {
+      this.logger = noopLoggerFactory(); // keep the test outputs clean
+      return;
+    }
     if (environment.isDesktop) {
-      this.logger = new WindowInjectedLogger();
+      this.logger = windowInjectedLoggerFactory();
       return;
     }
     if (environment.isNonProduction) {
-      this.logger = new ConsoleLogger();
+      this.logger = consoleLoggerFactory();
       return;
     }
-    this.logger = new NoopLogger();
+    this.logger = noopLoggerFactory();
   }
 }
+
+export type WindowAccessor = () => OptionalWindow;
+
+export type LoggerCreationFunction = () => Logger;
+
+type OptionalWindow = Window | undefined | null;
+
+function isUnitOrIntegrationTests(
+  environment: RuntimeEnvironment,
+  windowAccessor: WindowAccessor,
+): boolean {
+  /*
+    In a desktop application context, Electron preloader process inject a logger into
+    the global window object. If we're in a desktop (Node) environment and the logger isn't
+    injected, it indicates a testing environment.
+  */
+  return environment.isDesktop && !windowAccessor()?.log;
+}