Photon Realtime rejoin during client rollout: actor slots not guaranteed across old and new builds

I'm planning a zero-downtime migration for a small realtime app on Photon Engine. The current plan is to keep one Photon Cloud App ID so old and new client builds share the same rooms, and rely on PlayerTTL/EmptyRoomTTL plus rejoin with the same user ID so disconnected players resume their actor slot instead of re-entering as new actors.

The uncertainty is twofold. First, I don't know how long the rejoin window realistically stays valid for my setup — the TTL bounds appear to depend on configuration and possibly plan, and I can't assume an indefinite window. Second, the new build changes some event payloads, and I'm unsure what actually happens inside a shared room when an old client receives an event code or serialized format it doesn't recognize: silent drop, exception, or room-level failure.

There's also an unresolved hosting decision: stay on Photon Cloud, or move to self-hosted Photon Server for custom logic, knowing that server-side upgrades there seem to require draining rooms or accepting brief disconnects.

1. What is the documented behavior when a rejoin attempt arrives after PlayerTTL has expired — new actor, error, or room rejection?

2. How do mixed client builds behave in one room when event formats differ?

3. Given these constraints, what criteria should decide Cloud vs. self-hosted for this migration?