fix: avoid postgres 100-argument limit in findRollbackById

[dmtrTm]

What is this PR about?

Rolling back any application on canary fails with an opaque HTTP 400 "Error input: Rolling back". The real error is only in the backend log, and it is the query itself, before any rollback logic runs:

Error: Failed query: select "rollbacks"."rollbackId", ... json_build_array("rollbacks_deployment_application"...
    at findRollbackById (packages/server/src/services/rollbacks.ts:106)
  [cause]: PostgresError: cannot pass more than 100 arguments to a function
    code: '54023'

findRollbackById() hydrated deployment -> application -> environment -> project, so drizzle compiled every column of application plus one blob per nested relation into a single json_build_array(...) call. Postgres caps that at the hard-compiled FUNC_MAX_ARGS = 100.

At 99 columns the call sat at exactly 99 + 1 = 100 - right on the limit. 0175_fantastic_peter_quill.sql added networkIds and detachDokployNetwork, taking application to 101 columns, so every rollback now fails.

None of that nested data is actually read: the rollback router only uses deployment.applicationId, and rollback() / removeRollbackById() read the rollback row itself (deploymentId, image, fullContext) and re-fetch the application through findApplicationById(). Dropping the nested relations is enough, and tsc --noEmit confirms nothing else consumed them.

This is the same failure and the same fix shape as #4256 / #4257, which narrowed findPreviewDeploymentById. After this change, findRollbackById is no longer the odd one out: findDeploymentById, centralizedDeploymentsWith and findPreviewDeploymentById all narrow their nested application selection already.

The pressure was flagged in advance in #4240:

the application table already has 99 columns on canary, and Postgres caps json_build_array() at 100 arguments ... any additional column from any PR will re-trip this

How this was verified

Local Dokploy dev instance (canary @d768adb6a, Postgres 16.14, single-node swarm), application with rollbacks enabled against a local registry, two deployments, then Rollback:

• Before - HTTP 400, backend log shows PostgresError: cannot pass more than 100 arguments to a function (54023) raised from findRollbackById.
• After - the query executes, the 54023 error is gone entirely, and the rollback proceeds all the way into rollbackApplication().

Scope check on the same instance: project.all, project.one, application.one, deployment.all, domain.byApplicationId, schedule.list, volumeBackups.list and previewDeployment.all all return 200 - they already narrow their nested application selection.

Three other by-id finders do carry the identical un-narrowed shape and fail the same way on canary today. Calling them directly against the database (bypassing the routers) gives:

finPortById:          PostgresError 54023 (cannot pass more than 100 arguments to a function)
findScheduleById:     PostgresError 54023
findVolumeBackupById: PostgresError 54023

They are invisible from the API because their routers wrap the cause in a generic message the same way the rollback router does - port.one reports "Port not found", schedule.one and volumeBackups.one likewise - so the real error never reaches the client or the log. Unlike the rollback path, those three do read the nested data, so the correct fix there is columns: narrowing (the #4257 form) rather than dropping the relation. I kept this PR to the rollback path so it stays reviewable and independently verifiable; happy to send a follow-up for the other three, or to fold them in here if you prefer a single change.

Related: with this PR applied, rollback then hits a second, independent bug - ${{environment.*}} variables are not resolved during rollback - which is fixed in #4923. The two are separate one-liners in the same file but different functions; they do not conflict.

Checklist

Before submitting this PR, please make sure that:

• You created a dedicated branch based on the canary branch.
• You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
• You have tested this PR in your local instance.

Issues related (if applicable)

Same class of bug as #4256 / #4257 (findPreviewDeploymentById).

Screenshots (if applicable)

N/A - Backend query change, verified end to end as described above.