fix: respect destination_uuid in API for applications and services

[sharkcreep87]

Summary

• Fixes the API ignoring the destination_uuid parameter when creating applications or services, always deploying to the first destination on the server
• Applies the same fix pattern from PR fix api - set destination_uuid when creating databases #7002 (which fixed this for databases) to ApplicationsController and ServicesController
• Adds proper validation that returns a 422 error if the provided destination_uuid doesn't belong to the specified server

Fixes #8645

Changes

File	Method	Description
ApplicationsController.php	create_application()	Filter destinations by destination_uuid when provided
ServicesController.php	create_service()	Filter destinations by destination_uuid when provided
ServicesController.php	update_by_uuid()	Filter destinations by destination_uuid when provided

Test plan

• Create a server with 2+ Docker network destinations in the UI
• Call the API to create an application specifying the second destination's UUID → verify it deploys to the correct destination (not the first one)
• Call the API to create a service specifying the second destination's UUID → verify it deploys to the correct destination
• Call the API with an invalid destination_uuid → verify a 422 validation error is returned
• Call the API with a single destination on the server (no destination_uuid) → verify it still works as before (uses the only destination)

[sharkcreep87]

Self-review — this follows the exact same pattern already merged in PR #7002 for DatabasesController. All three locations are consistent:

1. ApplicationsController::create_application() ✅
2. ServicesController::create_service() ✅
3. ServicesController::update_by_uuid() ✅

Each correctly filters by destination_uuid when provided, with proper 422 validation if the UUID doesn't belong to the server. No regressions for single-destination servers (falls through to ->first()).