Allow duplicated services to target a different server

[DenisHoppe]

What problem will this feature address?

The Duplicate Services dialog currently allows selecting a new project or an existing environment, but it does not allow selecting a different deployment server.

The duplicate API also has no targetServerId. Because each source service record is copied into the create call, its existing serverId is retained. As a result, duplicated applications, Compose services, and databases are always assigned to the same server as their source, even when other registered remote servers are available.

This makes it unnecessarily difficult to use duplication for staging, load distribution, or creating a stateless copy on another host.

Describe the solution you'd like

Add an optional Target server selector to the existing Duplicate Services dialog.

• Default to the source server to preserve current behavior.
• List only accessible, active deployment servers with a usable SSH key, plus the local Dokploy server where supported.
• Add an optional targetServerId to the duplicate API and explicitly override the copied serverId for every selected service.
• Validate target-server access on the server side rather than trusting the submitted ID.
• Handle server-specific settings such as custom Docker networks by resetting them or requiring an explicit mapping when they are unavailable on the target.
• Clearly explain mount behavior:
  • file mounts can be recreated from stored configuration;
  • named-volume configuration may be duplicated, but volume contents are not copied;
  • bind mounts require the configured host path to exist on the target server.
• Show a confirmation summary containing the target project, environment, and server before duplication.

Full stateful migration and automatic volume transfer should remain separate from duplication and is already covered by #2260.

Suggested acceptance criteria:

1. A user can duplicate supported services to a different registered remote server.
2. Omitting the target server keeps the current source-server behavior.
3. Unauthorized, inactive, non-deployment, and source-equivalent targets are rejected appropriately.
4. The resulting service records contain the selected target serverId.
5. The UI warns that persistent volume data and bind-mount contents are not copied.
6. Server-specific network references cannot silently point to networks unavailable on the target.

Describe alternatives you've considered

• Duplicate on the current server and then manually edit the database: unsafe and unsupported because normal update schemas intentionally do not expose serverId.
• Recreate every service manually on the target server: works, but is slow and error-prone for services with substantial configuration.
• Use the migration workflow proposed in One-click migration of a service (volumes + configuration) to another server #2260: appropriate when existing runtime data must move, but unnecessarily complex when the desired result is a separate stateless duplicate.

Additional context

Current implementation observations:

• components/dashboard/project/duplicate-project.tsx only collects project/environment destination data.
• server/api/routers/project.ts duplicates service records by spreading the source entity into the corresponding create call, which retains serverId.
• Applications, Compose services, and supported database create schemas already accept serverId, so an explicit validated override fits the existing data model.

Will you send a PR to implement it?

Maybe, need help

[linear-code]

DOK-684