Fix Blank Editor for S3-hosted Files (>80KB) and Improve Upload UX (#1516)

[b-harsh]

Fixes #1516 #1516

Changes:

1. Root Cause Analysis (RCA)
   The Visibility Issue: Files under 80KB are stored in the database's content field. However, files exceeding 80KB are hosted on an S3 bucket, leaving the content field empty and providing a url instead. The editor component was previously only rendering the content property; since this was empty for S3 files, the editor window remained blank.

The UX Confusion: In uploader.js, large plaintext files are intercepted to be handled locally. Passing a string to Dropzone's done() callback automatically triggers an "error" state, rendering a red notification box that users mistook for an upload failure.

2. Proposed Changes
   A. Lazy-Loading S3 Content
   Action Implementation (client/modules/IDE/actions/files.js): Created fetchS3FileContent to handle asynchronous GET requests for files that have a url but no content.

Thunk Update (client/modules/IDE/actions/ide.js): Modified the setSelectedFile thunk. Now, whenever a file is selected, the IDE checks if it is a text file with missing content. If so, it triggers the fetch action to populate the editor on-demand.

B. UX Styling Improvements
Message Update (client/modules/IDE/actions/uploader.js): Updated the local interceptor message to be more descriptive.

CSS Enhancement (client/styles/components/_uploader.scss): Added a scoped override for .dz-error-message. When a file is marked with the .dz-success class, the background color now transitions to a success green, clearly indicating that the local handling was intended and successful.

3. Verification and Testing
   Since a local development environment typically lacks production AWS/S3 credentials, I verified the fix using a State Injection (Mocking) Strategy:

Redux State Manipulation: Temporarily exposed the store globally and manually cleared the content of a local test file while injecting a raw GitHub URL into the url property.

Selection Trigger: Clicked the modified file in the sidebar to trigger the updated setSelectedFile thunk.

Network Confirmation: Observed the Network Tab in Chrome DevTools to verify a successful GET request was fired to the mock URL.

State Consistency: Confirmed via store.getState() that the fetched text successfully replaced the empty state, allowing the editor to render the file content correctly.

4. Impact
   Users: Can now view and use larger scripts (e.g., jszip.min.js) that were previously inaccessible in the editor interface.

Clarity: The upload UX is now more intuitive, providing positive visual feedback for local file handling.

I have verified that this pull request:

• has no linting errors (npm run lint)
• has no test errors (npm run test)
• has no typecheck errors (npm run typecheck)
• is from a uniquely-named feature branch and is up to date with the develop branch.
• is descriptively named and links to an issue number, i.e. Fixes #123
• meets the standards outlined in the accessibility guidelines