🤖 test: make server lockfile failure deterministic

The lockfile-acquisition failure test relied on chmod-based permission errors, which can be unreliable in CI (e.g. privileged runners). Simulate failure by passing a muxHome path that is a file (not a directory), which triggers ENOTDIR after server startup.

Author: ammar-agent

src/node/services/serverService.test.ts

@@ -77,22 +77,19 @@ describe("ServerService.startServer", () => {
   }
 
   test("cleans up server when lockfile acquisition fails", async () => {
-    // Skip on Windows where chmod doesn't work the same way
-    if (process.platform === "win32") {
-      return;
-    }
-
     const service = new ServerService();
 
-    // Make muxHome read-only so lockfile.acquire() will fail
-    await fs.chmod(tempDir, 0o444);
+    // Use a muxHome path that is a FILE (not a directory) so lockfile.acquire() fails
+    // after the server has started.
+    const muxHome = path.join(tempDir, "not-a-dir");
+    await fs.writeFile(muxHome, "not a directory");
 
     let thrownError: Error | null = null;
 
     try {
       // Start server - this should fail when trying to write lockfile
       await service.startServer({
-        muxHome: tempDir,
+        muxHome,
         context: stubContext as ORPCContext,
         authToken: "test-token",
         port: 0, // random port
@@ -103,7 +100,7 @@ describe("ServerService.startServer", () => {
 
     // Verify that an error was thrown
     expect(thrownError).not.toBeNull();
-    expect(thrownError!.message).toMatch(/EACCES|permission denied/i);
+    expect(thrownError!.message).toMatch(/ENOTDIR|not a directory|EACCES|permission denied/i);
 
     // Verify the server is NOT left running
     expect(service.isServerRunning()).toBe(false);