getIconFile() does not verify physical file existence, causing broken icons with remote file systems (S3FS)

Problem/Motivation

ParagraphsType::getIconFile() assumes that if a file entity exists in the database for the given icon_uuid, the physical file also exists on disk. This is not always true when using remote file systems (S3FS with S3, Minio, GCS), where physical files can be lost independently of the database (bucket reset, storage migration, cache rebuild).

When this happens, getFileByUuid() returns the file entity, so restoreDefaultIcon() is never called. The generated icon URL points to a non-existent file, resulting in a permanent 404 with no self-healing path.

Current code (ParagraphsType.php, line 210):

$icon = $this->getFileByUuid($this->icon_uuid) ?: $this->restoreDefaultIcon();
 

Steps to reproduce

1. Configure Drupal to use a remote file system for public:// (e.g., S3FS module)
2. Create or import paragraph types with icons (icon_uuid + icon_default set in config)
3. Verify icons display correctly at /admin/structure/paragraphs_type
4. Delete the icon files from the remote bucket without touching the Drupal database
5. Clear caches (drush cr)
6. Visit /admin/structure/paragraphs_type
7. Result: Icons are broken (404). restoreDefaultIcon() is never triggered.

Proposed resolution

Add a file_exists() check in getIconFile() to verify the physical file before trusting the file entity. If the physical file is missing, delete the orphan entity and let restoreDefaultIcon() recreate the file from icon_default base64 data.

Remaining tasks

• Review and test proposed patch
• Consider static caching the file_exists() result to minimize remote I/O within a single request
• Add test coverage for the "file entity exists, physical file missing" scenario

User interface changes

None. Icons that were previously showing as broken (404) will self-heal and display correctly.

API changes

None.

Data model changes

None.