Rename Cloudflare Worker services

[JSONbored]

Problem: The API and UI Worker services carry the old brand name in their service identifiers, and Cloudflare Workers cannot be renamed in place.

Area: Infra / Cloudflare

Proposal: Provision two new Worker services under the new name with identical configuration and bindings, cut traffic over via routes, verify, then decommission the old services.

Deliverables:

• Two new Worker services live with all existing bindings (database, queue, environment variables) present.
• Old services decommissioned only after a verification window.

Acceptance criteria:

• Zero request errors observed during cutover.
• Every binding present on the old service is confirmed present on the new one before cutover.

Test scenarios:

• Run the project's production smoke-test script against the new services before flipping traffic.
• Monitor error rate for a defined window after cutover before decommissioning the old services.

Resources:

• The root and UI-app Worker configuration files.
• The project's production smoke-test script.

Boundaries:

• Keep the old Worker services live (even idle) until the verification window closes — don't delete on day one.

---

Part of #4761.

[linear-code]

JSO-3438

[JSONbored]

Addendum — Durable Object migration risk: the RATE_LIMITER binding (class RateLimiter, migration tag v1-rate-limiter in wrangler.jsonc) needs its own explicit handling here, distinct from the database/queue/env-var bindings already called out above. A Durable Object namespace's identity and storage are tied to the Worker script that owns its migration history, not to an abstract binding name — deploying a renamed script with the same DO config does not automatically inherit the existing RateLimiter instances/state. This needs a deliberate choice between Cloudflare's renamed_classes migration step (if it supports carrying a DO namespace across a script rename) versus accepting that in-flight rate-limit state resets on cutover (likely low-stakes for a rate limiter specifically, but should be a conscious decision, not an oversight). Flagging so it's verified against Cloudflare's actual current DO-migration support before the cutover, rather than discovered mid-migration.