fix(deploy): enable workers.dev subdomain on worker deploy

[sinameraji]

What

Live validation of the v0.3 M8 deploy-job delegation (build a worker in the CI sandbox → deploy it) surfaced a latent v0.2 bug: DeployDO uploads workers via the raw Workers Scripts API, which — unlike wrangler deploy — leaves the workers.dev subdomain disabled. The script uploads fine and reports success, but the worker returns 404 / error 1042 at <name>.<subdomain>.workers.dev, i.e. it's deployed but unreachable.

Evidence (live, on a real account)

The CI deploy-job delegation itself worked perfectly — the run log shows the sandbox-built artifact flowing to the deploy:

[build]  echo '…' > dist/worker.js         # built in the sandbox, NOT committed
[deploy] using CI-built dist/worker.js (103 bytes)   # handover
[deploy] deploy #3 success

But GET gitflare-ci-deploy-test.<sub>.workers.dev → 404. The Cloudflare API confirmed the script existed (GET script → 200) with subdomain: { enabled: false }, while wrangler-deployed workers had enabled: true. Enabling it via POST .../scripts/:name/subdomain {enabled:true} made the worker immediately serve HTTP 200 with the CI-built body.

Fix

After a successful script upload, uploadWorkerScript:

1. POST .../scripts/:name/subdomain { enabled: true } to expose it on workers.dev (best-effort; the deploy still counts as success either way), and
2. resolves the account's workers.dev subdomain to return a reachable url for the deployments UI.

Applies to both .gitflare/deploy.yml worker deploys (v0.2) and .gitflare/ci.yml deploy jobs (v0.3).

Tests

cf-deploy.test.ts updated: asserts the subdomain-enable POST fires with {enabled:true}, the returned URL is built from the account subdomain, and that a failed upload does NOT attempt any subdomain calls. 105 worker tests pass.

🤖 Generated with Claude Code