STRAWBERRY

Changes

• Fix docker-compose Application deployments (GitHub App path) not creating ServiceDatabase records for database services in docker-compose.yml.
• Persist detected database services for build_pack=dockercompose Applications by creating/updating service_databases rows scoped to the Application.
• Schema support: add nullable service_databases.application_id and make service_databases.service_id nullable so a ServiceDatabase can belong to either a Service (existing behavior) or a docker-compose Application.
• Add an Application-level Backups tab (only for docker-compose buildpack) to schedule and inspect backups for detected compose database services.
• Update backup execution paths (server resolution, container lookup, download route, status polling) to support Application-owned ServiceDatabase records.
• Prevent cleanup of Application-owned ServiceDatabase records as “orphaned” resources.

Issue

• Resolves https://github.com/coollabsio/coolify/issues/7528

Category

• Bug fix

Screenshots or Video (if applicable)

• Screen recording will be added before posting /claim #7528.

AI Usage

• AI is used in the process of creating this PR

Steps to Test

1. Create a new Application using the dockercompose buildpack via the GitHub App flow.
2. Use a repo that contains a docker-compose.yml with a database service (for example postgres:16-alpine) and at least one non-database service.
3. Deploy the Application.
4. Go to Project -> Environment -> Application -> Configuration -> Backups.
5. Expected: the database service is listed on the left and you can create a scheduled backup for it.
6. Run a backup and confirm a new execution entry is created and the download endpoint works.

Contributor Agreement

[!IMPORTANT]

• I have read and understood the contributor guidelines. If I have failed to follow any guideline, I understand that this PR may be closed without review.
• I have tested the changes thoroughly and am confident that they will work as expected without issues when the maintainer tests them