Fix plugin recovery for internal loader failures

[wisdomqin]

What changed

• Reject internal loader identifiers such as cordis:include as uninstallable plugin names.
• Extract duplicate loader entry IDs from the latest Harness startup attempt.
• Resolve a duplicate loader ID back to the actual configured third-party profile bundle by inspecting bundle patch manifests in profile order.
• Require the candidate package to exist in both profile dependencies and the bundle list before offering removal.
• Verify that both references are gone after updating the profile.
• Show a friendly package name in the recovery UI while preserving the full package name for the removal operation.
• Add coverage for internal loader identifiers, duplicate-entry resolution, scoped packages, removal verification, and recovery view labels.

Root cause

Some Harness composition failures are reported against an internal loader service, for example cordis:include, rather than the npm package that introduced the duplicate loader entry. The recovery UI previously treated that internal identifier as a package name, so it displayed the wrong target and attempted a removal that could never succeed.

User impact

For cases such as the dsh-tui duplicate storage entry, Desktop now resolves the failure to the configured profile package (for example @deepseek-harness-tui/dsh-tui) before showing the removal action. If the package cannot be verified reliably, the UI does not offer a misleading uninstall target.

Validation

• npm test — 24 test files, 139 tests passed
• npm run typecheck
• git diff --check origin/main...HEAD

Known follow-up

This PR covers startup failures reported by the Harness process. A separate client-side slot conflict can still appear after the backend reaches the ready state, such as the directory-picker conflict exposed by dsh-full-remote. That second-stage recovery path is intentionally not included here and should be reviewed as a follow-up.