fix(workflow): safely remap plugins during cross-environment import

[whyiug]

Summary

This fixes the cross-environment workflow import problem described in #1603. A plugin's toolId is local to one deployment, so importing the YAML into another environment used to drop the binding even when an equivalent plugin was already available there.

The importer still prefers the original ID. If that ID is unavailable, it now remaps only when there is exactly one compatible plugin in the current personal or space scope. Ambiguous or incompatible matches stay unbound and are reported to the user instead of being guessed.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Refactoring

Related Issue

Closes #1603

Changes

• add a versioned, portable plugin descriptor to exported workflow YAML (name plus a canonical schema fingerprint; no endpoint, credentials, or raw schema)
• preserve direct-ID compatibility, including existing draft plugins
• fall back only to a unique, formal, visible, same-version and schema-compatible plugin in the current personal/space scope
• replace the complete runtime identity together (pluginId, operationId, appId, version and derived inputs), or fail closed without leaving a partial binding
• return an import report while keeping the existing top-level Workflow response shape
• show unresolved plugin nodes after import so they can be selected manually
• validate space membership before importing into a requested space

Testing

• Existing tests pass
• New tests added
• Manual testing completed

Ran locally with Java 21 and Node.js 20:

• full console backend test suite: mvn test
• targeted workflow import suite: 18 tests, 0 failures
• backend CI gates: compile, Spotless, Checkstyle, SpotBugs and PMD
• frontend Prettier and ESLint checks
• frontend production build

The repository's full TypeScript check still reports pre-existing errors across unrelated files; the CI workflow treats that step as non-blocking, and none of the errors point to the files changed here.

Screenshots (if applicable)

Not included. The UI change is an import warning that only appears when plugin remapping cannot be done safely.

Checklist

• Code follows project coding standards
• Self-review completed
• Documentation updated (not needed for this bug fix)
• Breaking changes documented (none)

实现过程中使用了 OpenAI Codex（GPT-5）辅助分析调用链和补充测试。我逐项审阅了代码、权限边界和测试结果，并对这次提交负责。

[FenjuFu]

Verified against #1603. The importer preserves direct-ID behavior, safely remaps only a unique compatible plugin in the current personal or space scope, preserves workflow wiring, and reports unresolved mappings for manual action. Permission isolation, ambiguity, compatibility, and legacy-YAML behavior are covered. Full CI, CodeQL, DCO, and CLA are green; I also ran the 18-test WorkflowExportService suite plus Maven Spotless and Checkstyle locally. No blocking issues found.

[FenjuFu]

Reviewed against #1603 — the design matches all three expectations in the issue: automatic remap to the target environment's resource ID, directly usable after import, and explicit reporting of nodes that could not be mapped instead of silent failure. Failing closed on ambiguous matches rather than guessing is the right call.

One blocker before this can move: the branch is currently CONFLICTING with main. Could you rebase onto the latest main and force-push? CI is otherwise green (32/32).

---

已按 #1603 的验收点逐条核对：自动映射到目标环境资源 ID、导入后可直接调试发布、无法映射时明确提示失败节点 —— 三点都满足；对歧义匹配采取 fail-closed 而不是猜测，处理得当。

合并前的唯一阻塞项：当前分支与 main 存在冲突，麻烦 rebase 到最新 main 后 force-push。其余 CI 全绿（32/32）。

[whyiug]

谢谢你帮忙复核，也谢谢提醒冲突。我准备 rebase 时重新对照了最新 main：#1615 的实现已经随 #1623 合入主线，而且在唯一兼容映射和导入报告之外，又补齐了 agent tools、执行前 fail-closed、YAML 校验和对应回归；#1623 的完整 CI 与 CodeQL 也已通过。

继续 rebase #1611 需要手工合并几乎所有核心文件，还会让 portablePlugin 和当前 dependencyManifest 两套可移植元数据协议并存，回归和后续维护风险都会更高。剩余差异主要是 draft 插件处理和更窄的同名候选范围，也不适合直接叠加到当前主线设计。

所以这里不再 force-push，我先按已被 #1623 完整取代关闭。感谢你的认真 review，也感谢对 fail-closed 方案的认可。