Issue Description:
The current recovery logic uses a double buffering scan for commits, causing the page the device is searching for to spill into the next segment, which may not exist. In such cases, the device repeatedly retries to find the non-existent file, resulting in a 90-second hang and eventually a "blob not found" error. This causes all subsequent read/write requests to be canceled under the current implementation. In contrast, the local device creates the file when it encounters a non-existent file. This PR aims to align the behavior between both device implementations.

Steps to reproduce the bug:
Start garnet server with following flags

"--cluster",
"--aof",
"--use-azure-storage",
"true",
"--storage-string",
"UseDevelopmentStorage=true",
"--recover",
"true",
"--aof-commit-freq",
"0",

After the blob not found error, subsequent writes should fail to commit.

Screenshots

Expected Behavior