Handle pre-labeled PR deploy webhooks

[vigneshrajsb]

Summary

• handle pre-labeled PRs from the pull_request.opened payload instead of assuming a later label webhook is required
• queue the initial build immediately when the opened payload already includes lifecycle-deploy!
• keep the existing label-sync path for autoDeploy PRs that are opened without the deploy label
• add queue-key logging and regression coverage for the observed GitHub delivery sequence

Queue Key Decisions

• resolve-deploy uses a dedupe key of resolve:${buildId}:${fingerprint} with a short TTL so near-simultaneous PR events collapse into one effective resolve job
• build uses a deterministic jobId of build:${buildId}:${fingerprint}
• the fingerprint is build-scoped, not raw SHA-based, so rebuild inputs like comment runtime env, init env, repo-scoped rebuilds, and deploy-level overrides still produce a new queue key when they should

Verification

• pnpm test -- src/server/services/__tests__/github.test.ts
• pnpm exec eslint src/server/services/github.ts src/server/services/build.ts src/server/services/__tests__/github.test.ts
• unit scenarios covered:
  • non-autoDeploy PR opened with lifecycle-deploy!
  • autoDeploy PR opened with lifecycle-deploy!
  • unlabeled autoDeploy PR keeps label-sync behavior
  • labeled -> opened -> labeled pre-labeled autoDeploy PR only queues one effective build path
• local E2E scenarios validated on kind-lfc:
  • autoDeploy=true PR created with lifecycle-deploy! already present
  • autoDeploy=false PR created with lifecycle-deploy! already present