API: mutations require explicitly passing unrelated nullable fields (saveBuildType, saveEnvironment, registry.create)

Summary

When driving Dokploy through the HTTP/tRPC API (automation, provisioning), several mutations reject otherwise-complete payloads unless the caller explicitly passes fields that are unrelated to their use case and nullable in the DB. The web UI never hits this because it always submits every form field, but API consumers discover each required field by trial and error against BAD_REQUEST responses.

Cases we hit while integrating (Dokploy v0.29.x, still present in canary):

1. application.saveBuildType — apiSaveBuildType is built with .pick({...}).required() (packages/server/src/db/schema/application.ts), so setting buildType: "dockerfile" still requires explicitly sending herokuVersion: null and railpackVersion: null, fields that only apply to other build types.
2. application.saveEnvironment — apiSaveEnvironmentVariables requires buildArgs, buildSecrets and createEnvFile even when the caller only wants to set env.
3. registry.create — registryType: z.enum(["cloud"]) is a required single-value enum (packages/server/src/db/schema/registry.ts), so every caller must pass registryType: "cloud" even though no other value is accepted and the column already defaults to "cloud".

Proposal

Make these fields optional in the API schemas with the defaults the UI uses today:

• herokuVersion / railpackVersion → optional, default null.
• buildArgs / buildSecrets → optional, default null; createEnvFile → optional, default false.
• registryType → optional, default "cloud" (matching the column default), or drop it from the input schema entirely while it has a single accepted value.

This is backward compatible: payloads that pass today keep passing, and the generated OpenAPI surface stops requiring no-op fields.

Happy to send a PR (with tests) if you agree with the direction — flagging it first since it touches API validation.

Start with apiSaveBuildType and apiSaveEnvironmentVariables in the application schema at packages/server/src/db/schema/application.ts, then inspect the registry input schema in packages/server/src/db/schema/registry.ts. Add coverage for payloads that omit unrelated fields and verify the generated API validation accepts them with the stated defaults while existing payloads still pass.