guestlinks: prevent homoglyph and lowercase-collision attacks #3648

When sharing with email addresses we have to prevent malicious users from gaining access to shares which aren't supposed to be shared with them.

1. Lowercasing collisions. Guest IDs are lowercased with strings.ToLower to compare guests and build their storage keys (utils.CanonicalUserID, FSSafeUserID.SafeFilename). Unicode lowercasing turns some non-ASCII characters into ASCII ones, e.g. bob@İnfocorp.com → bob@infocorp.com and Kate@corp.com (Kelvin sign) → kate@corp.com. Mail delivery uses IDNA instead, so İnfocorp.com goes to xn--infocorp-o0e.com, a different domain. An attacker who controls that domain and gets invited as bob@İnfocorp.com ends up with the same identity and storage key as bob@infocorp.com, and with it access to that guest's shares.

2. Homoglyph. Addresses with look-alike characters (e.g. Cyrillic о in bоb@example.com) pass validation and are shown unchanged as the guest's ID and display name. A user can easily be tricked into sharing with an attacker's address, and an attacker's guest can't be told apart from the real person in share lists.

Proposed fix: guest identities are always canonical ASCII.

• graph Invite:
  • accept only a plain address;
  • require ASCII before the @;
  • convert international domains to punycode (look-alikes become visible as xn--…);
  • keep plain ASCII domains as they are;
  • lowercase the result.
• reva:
  • lowercase only ASCII A–Z in CanonicalUserID / SafeFilename;
  • the guestlinks auth manager rejects non-ASCII guest IDs, covering shares created directly in reva.