fix: close RolloutGate creation race window that allows prod to bypass staging ordering

[LittleChimera]

Summary

• Root cause: When a prod Environment and its Rollout are created simultaneously, the rollout controller can deploy freely during the window between Rollout creation and RolloutGate creation. The gate was being created after syncDeploymentHistory + buildRelationshipGraph — both GitHub API calls — introducing a multi-second delay.
• Secondary cause: Even after gate creation, AllowedVersions=nil is treated by the rollout controller as "no restriction" rather than "block all", so the gate didn't protect anything until updateAllowedVersionsFromRelationships ran a second time.

Observed incident: kuberik-demo prod deployed main-1779290372-b797408 at 15:19:48 but the prod gate wasn't created until 15:19:50, allowing prod to bypass the staging-before-prod ordering requirement.

Changes

1. Move createOrUpdateRolloutGate to before GitHub API calls in Reconcile. The gate now exists immediately on first reconcile, before any slow external calls.
2. Initialize AllowedVersions = [] (not nil) when relationship is configured. nil means "no restriction" in the rollout controller. An empty slice means "block all versions" — the safe default while the gate is being set up.

Test plan

• Deploy a new environment with relationship: { type: After } alongside its Rollout; verify no deployment happens before the gate's allowedVersions is populated by the upstream environment's bake success
• Verify existing environments with no relationship are unaffected (gate still created with allowedVersions=nil)
• Re-run kuberik-demo; staging should always bake before prod deploys the same version

🤖 Generated with Claude Code