Named resource profiles (organization-level groups) reusable across applications, databases and compose services

What problem will this feature address?

Resource limits/reservations (memoryReservation, memoryLimit, cpuReservation, cpuLimit) must be typed by hand on every application and database. In a real setup this leads to:

• The same 4 values copy-pasted across dozens of services (e.g. every "API"-type service on a given VPS tier gets the same numbers).
• No single place to see or change the sizing policy — bumping memory for all APIs means editing each service one by one, and values drift over time.
• Docker Compose services have no resource configuration in Dokploy at all; you have to hardcode deploy.resources in the compose file.

Describe the solution you'd like

Add organization-level Resource Groups, each containing named Resource Profiles, and let services reference a profile instead of typing values. Example:

KVM-2 (group)
  API    → cpuReservation=0.25 core, memoryReservation=512MB, cpuLimit=0.5 core, memoryLimit=1024MB
  WORKER → ...
KVM-4 (group)
  API    → ...

Proposed behavior:

• New Settings section "Resource Profiles" (same pattern as S3 Destinations / Registries): CRUD for groups and their profiles. A profile holds exactly the 4 values that already exist on services today (same units/format as the current form).
• On Applications and Databases (postgres, mysql, mariadb, mongo, redis, libsql), the Resources tab gets a "Profile" selector (group → profile). When a profile is selected the 4 fields show the inherited values, and each field can still be individually overridden. Effective value = override ?? profile value.
• The reference is live: editing a profile changes the effective values for every service that uses it, applied on the next deploy/redeploy (same moment the current fields are applied). No implicit mass-restart.
• Show on each profile how many services use it; deleting a group/profile that is in use is blocked.
• Docker Compose: in the compose settings, list the services parsed from the file and allow assigning a profile (+ per-field overrides) per compose service. At deploy time Dokploy injects deploy.resources.limits/reservations into the generated compose. If the compose file already defines deploy.resources for that service, the Dokploy assignment wins and a warning is shown.
• Nothing changes for services without a profile — current behavior is the default.

Describe alternatives you've considered

• Keep typing the 4 values on each service (status quo): works, but tedious and drifts across services.
• Convert everything to Compose and use deploy.resources in the file: only covers compose, and still duplicates values across stacks.
• A single per-server default limit applied to every service: too coarse, an API and a database on the same server rarely want the same sizing.

Additional context

Suggested scope, split so it can be reviewed in reasonable PRs:

1. Groups/profiles schema + tRPC router + Settings UI, and profile linking (with per-field overrides) on Applications and all database types, resolved in the existing calculateResources path.
2. Compose per-service profile mapping with deploy.resources injection into the generated stack file.

Will you send a PR to implement it?

Yes

Start with the existing calculateResources path and the Settings UI patterns used by S3 Destinations and Registries. Trace how applications, databases, and Compose services currently store and apply resource values, then implement the proposed groups, profiles, overrides, usage protection, and Compose injection; done means unchanged defaults still work and profile values apply on the next deploy.