getFile: return proper type

[alexcos20]

Changes proposed in this PR:

• use StorageObject as return for getFile function

[alexcos20]

/run-security-scan

[alexcos20]

AI automated code review (Gemini 3).

Overall risk: low

Summary:
This pull request refactors the file handling and checksum retrieval logic within the compute component and utils/file.ts. It introduces a new Storage abstraction to uniformly handle different file types (URL, Arweave, IPFS) when fetching file metadata and checksums. The changes simplify the getAlgoChecksums function by delegating specific file metadata fetching to the new Storage class and standardizes the return type of getFile to StorageObject[]. This refactoring aims to improve code readability, maintainability, and potentially fix underlying issues related to file metadata handling identified in the bug ticket.

Comments:
• [INFO][style] This change effectively abstracts the logic for fetching file metadata and checksums into the Storage class. This is a significant improvement for maintainability and reduces duplication. Ensure that the Storage.getStorageClass and storage.fetchSpecificFileMetadata methods are thoroughly tested for all supported StorageObject types (Url, Arweave, Ipfs) to prevent regressions.
• [WARNING][bug] The fileInfo.checksum ?? '' handles cases where checksum might be null or undefined. While this prevents runtime errors, please confirm if an empty string '' is an acceptable value for a content checksum in all scenarios, especially if the checksum is critical for data integrity validation. Ideally, fetchSpecificFileMetadata should either guarantee a non-empty checksum when forceChecksum is true, or propagate an error if it cannot be obtained.
• [INFO][style] Changing the return type of getFile to Promise<StorageObject[]> standardizes the output and aligns it with the new Storage abstraction. This improves type safety and simplifies downstream consumers of this function.

[alexcos20]

[WARNING][bug] The fileInfo.checksum ?? '' handles cases where checksum might be null or undefined. While this prevents runtime errors, please confirm if an empty string '' is an acceptable value for a content checksum in all scenarios, especially if the checksum is critical for data integrity validation. Ideally, fetchSpecificFileMetadata should either guarantee a non-empty checksum when forceChecksum is true, or propagate an error if it cannot be obtained.

Fixed in 5c5dc77