codesplitters: first rustybuns deploy with targets.edge.adopt, check the live Worker is taken over #170

Follow-up to #140 / #169.

targets.edge.adopt is on for codesplitters. With empty state, rustybuns plan shows [DB] adopted (the live codesplitters-db). The Worker still shows create. Alchemy skips the existing-resource lookup while a resource's props hold unresolved bindings, and the Worker's env has them until deploy.

From Alchemy's source (beta.77, WorkerProvider.ts), deploy should:

• upload as codesplitters, over the live script, not as a new random-named Worker;
• match the existing Durable Object classes by binding name (FILES → FileDurableObject, GAMES → GameRoom), so no class is re-created and no storage is lost.

None of this has run for real. The site is live, so watch the first deploy:

• rustybuns plan then rustybuns deploy from apps/codesplitters, with CLOUDFLARE_ACCOUNT_ID set to the notryanquinn account
• afterwards, only one codesplitters Worker and one codesplitters-db exist (wrangler deployments list --name codesplitters, wrangler d1 list)
• the site works and existing rooms and files are intact
• the next plan shows no changes, or only updates

If the DO migration is refused (wrangler's migration tag vs. Alchemy's), note the error here before retrying.

🤖 Generated with Claude Code