Shared instance fails to sync with "project has conflicting versions" error, naming project by raw ID with no way to identify the mod

[SuperLu122]

Please confirm the following.

• I checked the existing issues for duplicate problems
• I have tried resolving the issue using the support portal
• I have ensured my Modrinth App installation is up to date

What version of the Modrinth App are you using?

0.21.2

What operating systems are you seeing the problem on?

Windows

Describe the bug

When syncing a shared instance I received the error:

Invalid input: project `l3mWDgfy` has conflicting versions `oC0rXp8f` and `CyKh8XSr`

Two problems here.

First, the error identifies the project only by its base62 ID. There is no way for a user to
resolve that ID to a mod name. https://modrinth.com/mod/l3mWDgfy and
https://modrinth.com/project/l3mWDgfy both return 404, so the project appears to be unlisted,
private, or deleted. That leaves no path to finding out which mod is actually conflicting, and
therefore no way to fix it.

Second, the conflict itself seems to arise from the shared instance model. The instance owner
has one version of a mod in their instance, and I had separately installed a different version
of the same mod on top. Since owner-added content cannot be edited by the recipient, there is
no obvious way to resolve the duplicate from my side. Deleting jars from the mods folder does
not clear it, since the conflict is in the instance manifest rather than on disk.

The error fired twice in a row on the same sync attempt.

Steps to reproduce

1. Join a shared instance via the friends system
2. Install a mod into that instance at a version different from the one the owner has
3. Go to play the instance so it attempts to sync
4. See error

Expected behavior

Two things:

1. The error should name the mod, not just its project ID. Where the project cannot be
   resolved (unlisted, private, deleted), fall back to the filename from the manifest so
   the user has something actionable.

2. The app should offer a resolution path rather than just blocking the sync, for example
   prompting the user to keep the owner's version or their own, the same way the update
   review screen surfaces changes for approval.

Additional context

Two things:

1. The error should name the mod, not just its project ID. Where the project cannot be
   resolved (unlisted, private, deleted), fall back to the filename from the manifest so
   the user has something actionable.

2. The app should offer a resolution path rather than just blocking the sync, for example
   prompting the user to keep the owner's version or their own, the same way the update
   review screen surfaces changes for approval.