fix: isolate per-folder exception in mode picker for multi-project workspaces

[duzitong]

Problem

In McpPreferencePage.getWorkspaceNameForMode(), the entire workspace-folder loop was wrapped in a single try-catch. If any project in the workspace had a non-file:// URI (e.g. EFS-backed sftp://, ecf://, or other custom linked resources), Paths.get(URI.create(...)) would throw and the outer catch would return "" for all custom modes — hiding every custom mode from the mode picker dropdown.

Fixes #180

Changes

• McpPreferencePage.java: Move the Paths.get() call for each workspace folder into a per-folder inner try-catch. One bad URI now only skips that single folder; the loop continues for the remaining folders.
• Add INFO/WARN diagnostic log statements so future issues can be diagnosed from workspace.log without a debugger.

Testing

Manually verified in a two-project workspace where one project uses a non-file:// URI:

• Before fix: custom modes were hidden from the mode picker.
• After fix: modes scoped to the valid project appear correctly; the invalid-URI project is skipped with a WARN log entry.

[Copilot]

Pull request overview

Fixes issue #180 where multi-project workspaces containing a project with a non-file:// URI would cause the entire custom mode picker to be empty. The outer try/catch around the workspace-folder loop in getWorkspaceNameForMode is replaced with a per-folder try/catch so a single bad URI no longer aborts resolution for all custom modes. Additional diagnostic logging is added to aid future investigations.

Changes:

• Wrap the per-folder Paths.get(URI.create(folder.getUri())) call in its own try/catch so one invalid URI only skips that folder.
• Add diagnostic log statements throughout loadModeOptions and getWorkspaceNameForMode.
• Include the offending mode id and folder URI in error messages for easier triage.

Comments suppressed due to low confidence (1)

com.microsoft.copilot.eclipse.ui/src/com/microsoft/copilot/eclipse/ui/preferences/McpPreferencePage.java:1107

• The PR description mentions adding "INFO/WARN diagnostic log statements", but the per-folder failure is logged at ERROR level (LOGGER.error(...)) rather than WARN. Since a single bad folder URI is now an expected, non-fatal condition that the loop is designed to skip, WARN would more accurately reflect the severity and avoid noise in error monitoring.

  /**
   * Load per-mode tool status from preferences.
   */