fix: include deploy trigger in build dedupe key to prevent dropped deploys

[vigneshrajsb]

Problem

The resolve/build queue dedupe key was derived only from a build configuration fingerprint, not the commit being deployed. When two deploys of the same build were triggered close together — for example, two pushes to a tracked branch landing within the queue's dedupe window — both produced an identical key.

The build job is keyed by jobId, and a duplicate jobId enqueue is a no-op. So the second deploy was silently coalesced into the first: the newer commit never built, with no error and no log line. The only visible symptom is a missing deploy and a stale release.

Fix

• Append a per-trigger ref to the resolve dedupe id and the build jobId:
  • the pushed head commit for branch/static-env pushes, or
  • a unique run id for manual redeploys.
• Distinct triggers now get distinct keys (both deploys run), while genuine duplicates of the same trigger (e.g. a redelivered webhook) still coalesce as before.
• The ref is threaded from the resolve step into the build step so both queue layers agree on identity.
• A void/missing head commit falls back to the previous commit-agnostic key.
• Log when a build enqueue is coalesced, so the drop is observable instead of silent.

Tests

• Distinct trigger refs produce distinct keys; identical refs still coalesce.
• No-trigger fallback preserves the existing key.
• Push webhook and static-env push forward the pushed commit as the trigger; void head commit omits it.
• Dedupe-skip log fires when a matching build job already exists.