fix(pull-zone): Roll back bunny zone on creation/hostname failure

[carhensi]

Summary

• createPullZone and addCustomHostname are multi-step flows: bunny.net call → optional EU-mode / hostname / DNS → DB row. If a step after bunny.createPullZone fails, the zone was previously orphaned at bunny.net with no DB record — user retried, created another orphan.
• Wraps the post-create steps in a best-effort rollback try/catch. On failure, the just-created bunny zone is removed so the user can retry cleanly.
• Adopted zones (pre-existed in the user's account before our call, see PullZoneResult.adopted) are explicitly not rolled back — they belong to the user and pre-date our work.
• Cleanup failures are logged but never mask the original error.

Why pragmatic instead of saga / state machine

No DB migration, no schema change, happy path byte-identical. ~40 LOC of code change. Edge case where rollback itself fails is already covered by the implicit reconciliation in getPullZoneStatusFn (deletes DB row when remote is gone, src/serverFunctions/pull-zone.ts:236-239).

Test plan

• npm test — 221 / 221 (was 216 / 216 + 5 new)
• npm run typecheck — clean
• npm run code-check — clean
• Manual smoke: create pull zone with invalid hostname → verify no orphan at bunny.net dashboard
• Manual smoke: create pull zone on adopted name → verify zone preserved on later step failure

New tests

• createPullZone rolls back when setEuMode fails
• createPullZone rolls back when addHostname fails
• createPullZone does not roll back when adopted: true
• createPullZone cleanup failure does not mask the original error
• addCustomHostname rolls back addHostname when enableFreeSsl fails

Follow-up (separate PR)

• "Pull Zone bei bunny.net behalten / löschen"-Toggle beim Extension-Uninstall

🤖 Generated with Claude Code