Conflict resolution for uploading projects to cloud

[somebody1234]

Pull Request Description

• Close https://github.com/enso-org/cloud-v2/issues/1908
  • Add support for existing "conflicting files" modal for uploading local projects to Cloud

Important Notes

None

Testing Instructions

• Ensure "conflicting files" modal still works in all existing situations
• Ensure "conflicting files" modal works for right-click -> upload to cloud
• Ensure "conflicting files" modal works for multi-selecting projects and clicking the new "Upload to Cloud" button

Possible Future Extensions

• Downloading from Cloud to Local
• Support for triggering "conflicting files" modal via drag-n-drop (doable, just needs more added conditional logic)

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.
• If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
  or the Snowflake database integration, a run of the Extra Tests has been scheduled.
  • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

[MrFlashAccount]

LGTM, one nit below

[github-actions]

🧪 Storybook is successfully deployed!

📊 Dashboard:

• 👀 Review changes: https://www.chromatic.com/build?appId=673738989fc3e8430364197e&number=2679
• 👨‍🎨 Preview storybook: https://673738989fc3e8430364197e-ekczsgttnx.chromatic.com/

[PabloBuchu]

We now have 2 different dialogs to solve upload conflicts. The later (used for upload to cloud) don't have option to update the existing project. Would be nice to unify this

[somebody1234]

@PabloBuchu should be addressed now. i think the first dialog above is the old one so should be replaced with the new one at some point

[PabloBuchu]

Nope cant build to test

 INFO main_internal:Building.{self=Gui context=Context { .. } job=WithDestination { inner: BuildSource { input: BuildInput { mode: Production, version: Version { major: 2025, minor: 2, patch: 1, pre: Prerelease("dev") }, .. } }, destination: "/Users/pawelbuchowski/projects/enso/dist/gui" }}:Running process.{command=Command:
	cd "/Users/pawelbuchowski/projects/enso" && ENSO_IDE_COMMIT_HASH="14c46539b4b3587882e852a115e5d42b7878a74f" ENSO_IDE_VERSION="2025.2.1-dev" "/Users/pawelbuchowski/.nvm/versions/node/v22.14.0/bin/corepack" "pnpm" "run" "build:gui" "--mode=production"
	with working directory: /Users/pawelbuchowski/projects/enso
	with environment overrides:
		ENSO_IDE_COMMIT_HASH=14c46539b4b3587882e852a115e5d42b7878a74f
		ENSO_IDE_VERSION=2025.2.1-dev pid=7007 status=1}: ide_ci::program::command: close
DEBUG main_internal:Building.{self=Gui context=Context { .. } job=WithDestination { inner: BuildSource { input: BuildInput { mode: Production, version: Version { major: 2025, minor: 2, patch: 1, pre: Prerelease("dev") }, .. } }, destination: "/Users/pawelbuchowski/projects/enso/dist/gui" }}: enso_build::project: close
ERROR main_internal: enso_build_cli: error=Failed to build Gui.

[PabloBuchu]

@somebody1234 Now I can't upload any project to cloud. You are sending directory-/Users/pawelbuchowski/Documents/enso-projects as parentDirectoryId...

[somebody1234]

nice catch, thanks 😅

[PabloBuchu]

So default rename way of solving conficlits throws This field is invalid. It will work when I click rename and explicitely submit the input but thats not intuitive way. Rename should always be prepopulated with available name

[somebody1234]

@PabloBuchu fixed

[PabloBuchu]

Every time I click rename I get a default name even if I've changed it seconds ago... this is very misleading when I have multiple assets selected. Also probably we should add name taken validation as well

Screen.Recording.2025-04-29.at.10.38.26.mp4

[somebody1234]

should be fixed now :( definitely need to be more consistent with self-testing & i think we should start thinking about adding more tests.

this one i guess it's not trivial to add tests for because it requires local backend which isn't mocked yet but i assume not too difficult to add basic CRUD for. definitely not ideal vs a full integration test but i think it's worth the tradeoff of mocks being much faster/more reliable/less prone to network issues