[Tool Robustness] Implement global file-system exception mapping and retry policy in ErrorHandlingFileSystem #186959

Description

This is the central tracking ticket for the global FileSystem Robustness Initiative in flutter_tools.

Rather than maintaining flaky, repetitive try-catch structures and defensive existence checking at dozens of local call-sites throughout the codebase (which fail frequently and populate our top crash metrics), we should harden the foundational filesystem wrapper ErrorHandlingFileSystem (defined in error_handling_io.dart) to globally protect the CLI tool from all transient, permission, and missing-entity filesystem exceptions.

Root Causes & Gaps Addressed:

This unified initiative systematically closes the following critical gaps inside packages/flutter_tools/lib/src/base/error_handling_io.dart:

1. Omission of Async Operations (Cures Rank 9):
   ErrorHandlingFile and ErrorHandlingDirectory do not override and wrap basic asynchronous/read operations (such as readAsString(), exists(), listSync()). Any permission or locking errors thrown during these calls bubble up raw and crash the tool.
2. Missing Missing-Entity Handling (Cures Rank 7 & Rank 5):
   The exception handlers (_handlePosixException and _handleWindowsException) do not intercept missing-file errors (POSIX ENOENT [2], Windows ERROR_FILE_NOT_FOUND [2] and ERROR_PATH_NOT_FOUND [3]). Consequently, missing files throw raw PathNotFoundExceptions rather than exiting gracefully.
3. Windows File Sharing Lock Violations (Cures Rank 8):
   Antivirus scanners, OneDrive sync engines, and background IDE indexing daemons frequently place transient sharing locks on intermediate files inside build/ or .dart_tool/ on Windows. This throws a PathAccessException (OS Error 32 / 5). We currently have no retry backoff strategy to handle these transient locks.

Expected Resilient Behavior:

• Global Missing-Entity Mapping: If a file is missing, the tool should print a clean, user-friendly error explaining the situation (suggesting running flutter clean) and terminate cleanly via ToolExit rather than throwing raw stack traces.
• Windows Locking Retry Backoff: When a transient sharing violation (OS Error 32 or 5) is encountered on Windows, ErrorHandlingFileSystem should automatically wait a few milliseconds and retry up to 5 times, letting the background antivirus or indexer release the lock and successfully completing the build rather than crashing.
• Full Async Wrapping: All asynchronous operations on files and directories are wrapped cleanly, ensuring no raw filesystem exceptions escape unhandled out of asynchronous zones.

Proposed Solution

• Flesh out ErrorHandlingFile, ErrorHandlingDirectory, and ErrorHandlingLink with exhaustive overrides for all interface methods, wrapping them in _run / _runSync.
• Update _handlePosixException to map code 2 (enoent).
• Update _handleWindowsException to map codes 2 (kFileNotFound) and 3 (kPathNotFound).
• Implement an automated exponential backoff retry loop inside the _run/_runSync execution wrappers for Windows lock codes (5, 32, 33, 1224).