fix: Remove lock condition from mtime update for consistency

The mtime update logic in the `inode == parent` path was inconsistent
with the `inode != parent` paths. In child directories (inode != parent),
mtime updates occur regardless of the `lock` parameter. However, parent
directories (inode == parent) only updated mtime when lock=true.

This inconsistency meant that when lock=false (e.g., called from Rename),
parent directories wouldn't get their mtime updated even when new items
were found, leading to potentially stale timestamps.

Remove the `&& lock` condition to ensure mtime updates happen consistently
across all code paths whenever a directory is already sealed but new items
are discovered during listing.

Fixes review comment from Cursor bot.

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

Co-Authored-By: Claude <[email protected]>

Author: ovaistariq

core/dir.go

@@ -296,6 +296,7 @@ func (parent *Inode) sealChildDirectories(dirs map[*Inode]bool, resp *ListBlobsO
 			if atomic.LoadUint64(&child.dir.generation) != gen+1 {
 				// Seal failed validation - directory was modified concurrently
 				// This should not happen since we hold child.mu, but be defensive
+				fuseLog.Debugf("Seal failed validation for directory %v: generation=%v expected=%v", child.FullName(), atomic.LoadUint64(&child.dir.generation), gen+1)
 			}
 		}
 		child.mu.Unlock()
@@ -435,8 +436,8 @@ func (parent *Inode) listObjectsSlurp(inode *Inode, startAfter string, sealEnd b
 			sealSucceeded = parent.sealDirWithValidation()
 			alreadySealed = !sealSucceeded && parent.dir.listDone
 
-			// Special case: if already sealed but got items, update mtime (lock=true only)
-			if alreadySealed && hasItems && lock {
+			// Special case: if already sealed but got items, update mtime
+			if alreadySealed && hasItems {
 				parent.updateDirectoryMtime()
 			}