[Feature Request] Carry forward or migrate conversation workspace data across agent re-publishes

### Self Checks

- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed.
- [x] Please do not modify this template :) and fill in all the required fields.

### 1. Is this request related to a challenge you're experiencing? Tell me about your story.

We run a long-lived agent conversation on self-hosted Dify 1.17.0 that accumulates artifacts in its workspace over many messages (reports, intermediate results). At some point we fixed a prompt/skill and re-published the agent — and the conversation's accumulated workspace data became unreachable for subsequent runs: the workspace binding belongs to a specific config/home generation, and `AgentWorkspaceService.validate_binding_generation()` (`api/services/agent/workspace_service.py`) raises `AgentWorkspaceBindingGenerationMismatchError` when the agent's config version or home snapshot changed. The app generator scopes session reuse by immutable published snapshot ids (`api/core/app/apps/agent_app/app_generator.py`, `_session_scope_config_version_id` docstring: *"Published/web/API runs use immutable published snapshot ids. This keeps Workspace Binding continuity inside one editable surface without mixing draft/build/published state."*).

The isolation-by-generation design itself is sound (we would not want a run mixing state across config versions). The pain is that there is **no path to carry forward or migrate the conversation's workspace data** onto the new generation — from the user's point of view, a routine re-publish quietly orphans everything that conversation had built up. The old workspace is only reclaimed later by the resource collection task.

### 2. Additional context or comments

Source references from the `1.17.0` tag. Two of the directions that would help us:

- an opt-in "carry forward workspace content on re-publish" (e.g. copy/merge the old conversation workspace into the new generation's workspace, possibly as a quarantined subdirectory the agent can explicitly promote), and/or
- an agent-scoped shared workspace surface as discussed in the related request for agent-level persistent storage (#41375).

Also worth noting: the console sandbox file browser (`AgentAppSandboxService`) can still read the old binding's files for a while, but there is no user-facing action to migrate them forward.

### 3. Can you help us with this feature?

- [ ] I am interested in contributing to this feature.

Start with api/services/agent/workspace_service.py, especially validate_binding_generation(), then trace session scoping in api/core/app/apps/agent_app/app_generator.py. Review the related agent-level persistent storage request (#41375) and the AgentAppSandboxService behavior. Done should mean a defined, user-facing path that preserves or migrates conversation workspace data after an agent is re-published without mixing generations.

Written by the indexing model from the issue text.