fix: Agent and sync bugs - #259

Type of change

• 🐛 Bug fix
• 🚀 New feature
• ❓ Other (please specify)

Description

Fixes applications getting permanently stuck on "Syncing"/"Unknown" status and history filling up with spurious "Failed" (hub restarted before the operation result was received) entries, caused by duplicate webhook deliveries (e.g. GitHub retrying a package event for GHCR pushes).

• Image pull webhook: the agent silently dropped its response to the hub whenever an image pull found nothing new to pull — even for explicitly triggered requests (webhook/manual/GitHub Actions), not just background polling ticks. When GitHub redelivers a webhook, the second delivery finds the image already pulled by the first and never reports back. The corresponding application_event then sits in running forever (only cleared on the next hub restart, which is where the "hub restarted..." failures come from), and the application's sync_status never gets reset out of Syncing.
• Commit-sync / deployment webhooks: the same class of duplicate-delivery problem existed here too, plus a more serious gap — there was no locking at all preventing two overlapping deploys for the same application from running concurrently on the agent (docker compose up racing against itself for the same project directory).

Notes for reviewers

• No commit/deploy correctness change is required beyond serialization — the deploy path already always reports a result back to the hub (unlike the image-poll path before this fix), so it doesn't get permanently "stuck"; it was purely a concurrency/race risk.
• The repository-level sync lock is released once the sync call returns (i.e. once jobs are enqueued), not once the deploy actually finishes. In practice this is fine because the agent-side lock added here serializes the actual work — a residual reordering (rather than corruption) risk remains for genuinely back-to-back distinct triggers, which is an acceptable tradeoff over the added complexity of holding the lock across async queue processing.