Updating Dokploy does not update the `dokploy-traefik` container to the newly pinned Traefik version

To Reproduce

1. Install Dokploy at a release pinning an older Traefik (e.g. v0.29.13 → 3.6.7).
2. Upgrade Dokploy to v0.30.2 (pins 3.6.25).
3. docker exec dokploy-traefik traefik version
4. Observe the old version still running.

Current vs. Expected behavior

Expected behavior

After upgrading Dokploy to v0.30.2, dokploy-traefik runs traefik:v3.6.25.

Actual behavior

dokploy-traefik continued running traefik:v3.6.7

Provide environment information

- Dokploy updated from **v0.29.13 → v0.30.2**
- Docker on Linux

Which area(s) are affected? (Select all that apply)

Traefik, Installation

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

Impact

1. Traefik upstream security patches never land in production.
2. Traefik bundles lego, so a stale Traefik means stale ACME code.
3. An already fixed Traefik <-> Docker Engine incompatibility can resurface anytime #4324 #4123

Example to what Nr.2 can lead

In my case the running Traefik (v3.6.1, meaning the container had already been stale for several upgrades before this one) carried a lego version whose Infomaniak DNS provider could not parse
the provider's API response (json: cannot unmarshal number into Go struct field APIResponse[string].data of type string, fixed upstream in lego v5.2.0 via
go-acme/lego#3139, vendored into Traefik from 3.6.22 onward).

Consequences:

• Let's Encrypt DNS-01 renewal failed silently for 30 days and the certificate expired, taking the
  sites down.
• Every failed attempt created a _acme-challenge TXT record it could not clean up, because the
  record ID it needed for deletion was in the response it failed to parse. 60 orphaned TXT records
  accumulated in the zone.
• The fix was already present in the Traefik version my installed Dokploy pinned. It simply never
  got applied, so the outage happened on a system that was nominally up to date.

Workaround

In Web Server -> Traefik -> Additional Port Mappings -> save (even with no changes), recreates the container, picking up the pinned image.

Suggested fix

I appreciate not recreating Traefik automatically avoids surprise downtime, so a few options in
increasing order of intrusiveness:

1. Surface the drift. Show the running Traefik version alongside the pinned version in Web
   Server settings, and flag when they differ. Silent drift is the core problem.
2. Add an explicit "Update Traefik" action in the UI
3. Warn on Update when the running container's image differs from TRAEFIK_VERSION
4. Optionally recreate automatically, behind a setting that is off by default.

Will you send a PR to fix it?

No

Start from the Web Server → Traefik settings and the update path that handles Additional Port Mappings, then trace how the pinned TRAEFIK_VERSION becomes the dokploy-traefik container image. Reproduce the upgrade from v0.29.13 to v0.30.2 and compare the pinned and running versions. Done means the stale-image condition is surfaced or an explicit update path reliably applies the pinned Traefik version without an unplanned recreation.