Fix #4977 Modrinth 依赖可以指向已经被删除的项目

[burningtnt]

该 PR 建议在 #5026 后合并，否则可能会 DOS 服务器

[Copilot]

Pull request overview

This pull request fixes issue #4977 where Modrinth dependencies can point to deleted projects that no longer exist. The fix introduces a graceful degradation mechanism that returns a BROKEN sentinel value instead of throwing exceptions when resolving dependencies that point to deleted projects.

Key Changes

• Introduces a new resolveDependency() method in the RemoteModRepository interface with a default implementation that delegates to getModById()
• Implements special error handling in ModrinthRemoteModRepository.resolveDependency() to catch errors for deleted projects (502 errors and FileNotFoundException) and return RemoteMod.BROKEN
• Refactors dependency loading in DownloadPage to use asynchronous parallel loading, preventing UI blocking when multiple dependencies need to be resolved

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
HMCLCore/src/main/java/org/jackhuang/hmcl/mod/RemoteModRepository.java	Adds default resolveDependency() method to the interface that delegates to getModById()
HMCLCore/src/main/java/org/jackhuang/hmcl/mod/modrinth/ModrinthRemoteModRepository.java	Overrides resolveDependency() to handle deleted projects by catching 502 and FileNotFoundException errors; also expands wildcard imports to explicit imports
HMCLCore/src/main/java/org/jackhuang/hmcl/mod/RemoteMod.java	Updates Dependency.load() to use resolveDependency() instead of getModById() for graceful handling of deleted dependencies
HMCL/src/main/java/org/jackhuang/hmcl/ui/versions/DownloadPage.java	Refactors loadDependencies() from synchronous to asynchronous parallel loading using Task API to prevent UI blocking; expands wildcard imports to explicit imports

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This TODO comment mentions that massive tasks may cause OOM (Out of Memory). Consider adding more details about the specific concern or a reference to an issue number. This would help future developers understand the context and potential mitigations needed.

Suggested change

	// TODO: Massive tasks may cause OOM.
	// TODO: Loading a very large number of dependencies will create one Task per dependency
	// and collect all resulting UI nodes into memory at once via Task.allOf(...).
	// For extremely large modpacks this may increase peak memory usage significantly
	// and could lead to OOM on low-memory systems. Consider introducing batching or
	// streaming of dependency loads (while still updating the UI on the JavaFX thread)
	// if real-world usage exposes memory issues here.

[Copilot]

The resolveDependency method is only overridden for Modrinth but not for CurseForge. This creates inconsistent behavior where Modrinth dependencies gracefully handle deleted projects by returning RemoteMod.BROKEN, while CurseForge dependencies would throw an exception. Consider implementing similar handling for CurseForge to maintain consistent behavior across different mod repositories.

Suggested change

	return getModById(id);
	try {
	return getModById(id);
	} catch (IOException e) {
	return RemoteMod.BROKEN;
	}