[Bug] System booking emails generate reschedule/cancel links with cal.com TLD instead of cal.eu on app.cal.eu instance

[tratamentes]

Is your proposal related to a problem?

Yes.

On the app.cal.eu instance, the system booking confirmation email sent to attendees contains reschedule and cancel links pointing to cal.com instead of cal.eu.

Expected: https://app.cal.eu/reschedule/{uid}
Actual: https://app.cal.com/reschedule/{uid}

Expected: https://app.cal.eu/booking/{uid}?cancel=true
Actual: https://app.cal.com/booking/{uid}?cancel=true

Because booking data is isolated to the EU shard database, clicking these links results in "Booking not found" / 404. Attendees cannot reschedule or cancel using the links in the confirmation email.

Describe the solution you'd like

The bookerUrl used to construct reschedule and cancel links in system emails (packages/core/builders/CalendarEvent/builder.ts) must resolve from the shard's origin, not fall back to a hardcoded or globally defaulted cal.com domain.

When a booking originates from app.cal.eu, all derived links must use app.cal.eu as the base URL.

Describe alternatives you've considered

Workflow-based overrides ({RESCHEDULE_URL} / {CANCEL_URL} variables in custom email templates) can work around this — but this is a regression in core system email behaviour that should not require a workaround.

Additional context

Instance: app.cal.eu
Affected email: booking confirmation sent to attendee after BOOKING_CREATED
Affected links: rescheduleLink and cancel link constructed in packages/core/builders/CalendarEvent/builder.ts via bookerUrl
Impact: all attendees on the EU instance receive broken action links in confirmation emails

A similar bookerUrl resolution bug was previously fixed for team events in #12147 / PR #12261. This may be the same root cause affecting the EU shard specifically.

Requirement/Document

The fix should ensure that bookerUrl in CalendarEvent/builder.ts is derived from the shard's runtime origin (NEXT_PUBLIC_WEBAPP_URL for app.cal.eu), not from any hardcoded global constant.

[Souissi4]

I traced the specific divergence. In CalendarEventBuilder.ts (fromBooking), bookerUrl is resolved as:

const organizationId = user.profiles?.[0]?.organizationId ?? null;
const bookerUrl = await getBookerBaseUrl(eventType.team?.parentId ?? organizationId);

This imports from @calcom/features/ee/organizations/lib/getBookerUrlServer. When both team.parentId and organizationId are null which is always the case for non-org users on app.cal.eu — that function falls back to a build-time constant that resolves to cal.com.
By contrast, handleCancelBooking.ts imports from @calcom/lib/getBookerUrl/server and additionally passes ownerProfile?.organizationId as a fallback. That's why cancel works correctly in some flows but breaks in BOOKING_CREATED emails.
The fix would be to align CalendarEventBuilder.fromBooking with the pattern in handleCancelBooking.ts: either switch to @calcom/lib/getBookerUrl/server and include the ownerProfile fallback, or ensure the ee/organizations version's null-fallback reads NEXT_PUBLIC_WEBAPP_URL at runtime rather than a build-time constant.