fix: correct locking system integration test logic

- Fix test that incorrectly expected same operation to proceed after being started
- Update test to properly validate conflict detection behavior:
  - Check operation can proceed before starting
  - Verify same operation is blocked after starting (self-conflict)
  - Confirm operation can proceed again after completion
- Test now correctly validates the WRITE-vs-WRITE conflict detection
- All 773 tests now pass with 100% success rate

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

Author: jpicklyk

src/test/kotlin/io/github/jpicklyk/mcptask/integration/LockingSystemIntegrationTest.kt

@@ -223,18 +223,25 @@ class LockingSystemIntegrationTest {
 
         // When
         sessionManager.updateActivity(sessionId)
+        
+        // Check operation can proceed before starting
+        assertTrue(lockingService.canProceed(operation))
+        
         val operationId = lockingService.recordOperationStart(operation)
 
         // Then
         assertTrue(sessionManager.isSessionActive(sessionId))
         assertEquals(1, lockingService.getActiveOperationCount())
 
-        // Verify operation can proceed
-        assertTrue(lockingService.canProceed(operation))
+        // Verify same operation is now blocked (conflict with itself)
+        assertFalse(lockingService.canProceed(operation))
 
         // Complete operation
         lockingService.recordOperationComplete(operationId)
         assertEquals(0, lockingService.getActiveOperationCount())
+        
+        // After completion, operation should be able to proceed again
+        assertTrue(lockingService.canProceed(operation))
     }
 
     @Test