Summary

Resolves #7528 — Enables automated database backups for Docker Compose applications deployed via GitHub App (dockercompose buildpack).

Currently, database detection and backup scheduling only work for Empty Docker Compose and one-click services (Service model path). Git-based Docker Compose deployments (Application model path) detect databases via isDatabaseImage() but never create ServiceDatabase records, so backups are unavailable.

This PR adds full backup support by:

1. Database Detection & Persistence (Backend)

• In parseDockerComposeFile(), the Application model path now creates ServiceDatabase records for detected database containers (PostgreSQL, MySQL, MariaDB, MongoDB)
• Records are linked via a new application_id column (nullable) on service_databases, with service_id made nullable to support dual ownership
• Database image changes in compose are automatically tracked and updated

2. Backup Configuration UI

• Adds a Database Backups menu item in the Application configuration sidebar (only shown for dockercompose build pack when databases are detected)
• Reuses the existing CreateScheduledBackup and ScheduledBackups Livewire components — no new backup logic needed
• Users can create, configure, and monitor scheduled backups for each detected database

3. Backup Execution

• DatabaseBackupJob updated to resolve server, container name, and network from application-owned ServiceDatabase records
• Container name resolution uses docker ps label filtering to find the actual running container (handles both consistent and non-consistent naming)
• S3 upload network resolution handles both Service and Application parents

4. Deployment Safety (Overlapping Re-deployments)

• Backup job checks isDeploymentInprogress() before executing for application-owned databases
• If a deployment is running, the backup is skipped and logged (prevents incomplete/corrupted backups)

5. Compose Changes Handling

• When parseDockerComposeFile() runs (on each deploy), stale ServiceDatabase records are automatically cleaned up if the database service was removed from the compose file
• Application::deleting() hook cleans up all compose database records and their scheduled backups when the application is deleted

Files Changed

New files (3):

• database/migrations/2026_03_07_000001_add_application_id_to_service_databases.php
• app/Livewire/Project/Application/ComposeDatabaseBackups.php
• resources/views/livewire/project/application/compose-database-backups.blade.php

Modified files (7):

• app/Models/ServiceDatabase.php — Dual ownership (Service or Application), getServer(), containerName(), updated team queries
• app/Models/Application.php — composeDatabases() relationship, cleanup on deletion
• app/Models/ScheduledDatabaseBackup.php — Updated server() resolution
• app/Jobs/DatabaseBackupJob.php — Application-owned database support, deployment safety check
• bootstrap/helpers/shared.php — ServiceDatabase creation in Application path, stale record cleanup, team resolution
• resources/views/livewire/project/application/configuration.blade.php — Database Backups menu item
• routes/web.php — project.application.database-backups route

Backward Compatibility

• service_id remains the primary FK for existing Service-owned databases (unchanged behavior)
• application_id is nullable, defaulting to null for all existing records
• No changes to existing Service model path or one-click service behavior

/claim #7528