Session identity stitching (v3.3.1) silently overwrites the linked distinctId when two different users share the same session hash (IP + User-Agent)

Describe the Bug We run Umami for an internal application where many users connect through a shared corporate network/VPN, and often use the same standardized device/browser (identical OS + browser version across the org). Because the session identifier is derived from IP + User-Agent + hostname + website, different real users frequently collide on the same session hash. Since 3.3.1 introduced session identity stitching (linking a session to a distinctId on identify()), this collision has a damaging effect: when a second, genuinely different user identifies on the same colliding session, their identify() call silently overwrites the previously linked identity — the session's Properties/Distinct ID switch from the first user to the second, with no indication that two different people were ever linked to that session. Steps to reproduce Two different user accounts, on two different physical devices, but sharing the same public IP (VPN/corporate NAT) and an identical User-Agent …