feat: make schedule execution results discoverable (deployment.one, exit code, docs fix)

Rewritten after reading the source: the original version of this issue claimed schedule execution results were unavailable through the API. That was wrong — it was based on the published API reference rather than the code. Most of the capability already exists. What follows is the accurate, much narrower request.

What problem will this feature address?

Reading the outcome of a schedule execution is possible today, but it is effectively undiscoverable, and one piece of information is missing outright.

What already works, and is not documented:

• schedule.runManually returns { status, deploymentId, logPath }. The API reference documents an empty {} response, which is what a reader will act on.
• Schedule executions are recorded in the deployment table with a nullable scheduleId, so deployment.allByType?id=<scheduleId>&type=schedule returns them with status, startedAt, finishedAt and errorMessage.
• deployment.readLogs?deploymentId=…&tail=… returns the output.

Because the read path lives under the deployment router rather than the schedule one, and because the documented runManually response hides the deploymentId, someone building a pipeline around Schedule Jobs will reasonably conclude the result is unavailable — and then either scrape something undocumented or continue blindly after triggering a job.

Two real gaps remain:

1. No way to fetch a single deployment by id. To poll the execution you just triggered, you must call deployment.allByType for the entire schedule and filter client-side.
2. No exit code. status is running | done | error | cancelled, which is enough to gate pass/fail, but the command's actual exit status is lost — which matters when a script signals different failure modes by code.

Describe the solution you'd like

1. deployment.one — GET /deployment.one?deploymentId=…, mirroring the permission checks already implemented in deployment.readLogs.
2. An exitCode column on deployment, populated by the schedule runner and exposed on the deployment object; null where it does not apply.
3. Fix the documentation: document the real { status, deploymentId, logPath } response of schedule.runManually, and cross-reference the schedule → deployment read path from the Schedule Jobs page.

Item 3 is by far the highest value of the three. The capability exists; it simply cannot be found.

Describe alternatives you've considered

• Listing and filtering client-side — what one must do today. It works, but it transfers an entire execution history to read a single row, and it is awkward to reason about when a cron firing overlaps a manual run.
• Failure notifications (#2099, #4210) — complementary rather than a substitute: asynchronous, out-of-band, and not correlated to a specific invocation.
• New schedule-specific endpoints such as schedule.executions — this would duplicate what deployment.allByType already does. Reusing the deployment router looks like the right call; it needs a single-item read and documentation, not a parallel surface.

Additional context

• apiFindAllByType already accepts "schedule" (packages/server/src/db/schema/deployment.ts), and deployment.allByType has a dedicated schedule branch with its own permission handling.
• deployment.allByType and deployment.readLogs are both already present in openapi.json, so item 1 needs no new surface beyond the procedure itself.
• Docs pages concerned: https://docs.dokploy.com/docs/api/reference-schedule and https://docs.dokploy.com/docs/core/schedule-jobs

Will you send a PR to implement it?

Maybe, need help

Start with packages/server/src/db/schema/deployment.ts and the existing deployment.allByType and deployment.readLogs procedures, then trace schedule.runManually and the schedule runner. Review the two linked documentation pages and the documented API responses. Done means deployment.one, exitCode handling, and corrected schedule execution documentation are implemented with the existing permission behavior preserved.