ci(deploy): add Vercel staging deployment

[RSO]

Summary

• Adds a required target_environment input to the reusable Vercel deployment workflow.
• Preserves the existing production path with vercel deploy --prod --skip-domain while supporting Vercel custom environments through vercel deploy --target=<environment>.
• Adds a manual Deploy Web to Staging workflow that deploys both kilocode-app and kilocode-global-app to their Vercel staging environments in parallel.
• Makes every existing production and manual-redeploy caller explicitly select production.

Verification

• N/A — workflow-only change.

Visual Changes

N/A

Reviewer Notes

• Temporarily enabled the workflow on PR ci(deploy): add Vercel staging deployment #3993 and successfully deployed both Vercel staging environments; the PR trigger was removed after verification, leaving the workflow manual-only.
• The test identified and filled missing staging-only Vercel configuration. Worker URLs point to intended *.staging.kiloapps.io hosts, callback/access secrets are staging-specific, and the global app shares the regular app's staging DB, Redis, session-ingest, and Linear configuration.
• Staging does not call vercel promote; Vercel assigns each deployment to the custom staging environment.
• All current production paths retain vercel deploy --prod --skip-domain followed by the existing production promotion jobs.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The previous WARNING (unscoped concurrency group on the pull_request trigger) has been resolved by the latest commit, which removes the pull_request trigger entirely — the staging deploy workflow is now workflow_dispatch-only.

Files Reviewed (4 files)

• .github/workflows/deploy-staging.yml — previously flagged pull_request trigger removed; no issues
• .github/workflows/stage-vercel-deployment.yml — no issues
• .github/workflows/deploy-production.yml — no issues
• .github/workflows/redeploy-web.yml — no issues

Fix these issues in Kilo Cloud

---

_{Reviewed by claude-4.6-sonnet-20260217 · 289,362 tokens}

_{Review guidance: REVIEW.md from base branch main}

[kilo-code-bot]

WARNING: Concurrency group is not scoped per PR

The static group: deploy-staging means all open PRs share one concurrency slot. With cancel-in-progress: false, PRs queue behind each other — PR B's staging deploy won't run until PR A's finishes. Worse, whichever PR deploys last wins the single staging environment, so earlier PRs lose their staging URL without any explicit cancellation.

Consider scoping the group to the PR head ref so each PR gets its own slot:

Suggested change

	cancel-in-progress: false
	group: deploy-staging-${{ github.head_ref || github.run_id }}

You may also want cancel-in-progress: true so a force-push to the same PR cancels the in-flight deploy rather than queueing another one behind it.

---

_{Reply with @kilocode-bot fix it to have Kilo Code address this issue.}