willchen96 tidies up Mike's sharing model

A small fix removes a confusing wrinkle in how project membership is displayed and stored.

multi-tenantworkflow

Owners of a project or tabular review could previously share it with their own email address - harmless from an access standpoint, but it cluttered member lists and produced ambiguous-looking states where someone appeared to grant themselves access they already had. willchen96's change rejects self-shares at the API and blocks them in the UI surfaces that lead there, so the rule is enforced end-to-end rather than only at one layer.

The same pass also normalizes and deduplicates share entries before they're saved, killing the adjacent bug where the same collaborator could show up multiple times with different casing or stray whitespace. The author is explicit that this isn't a security fix - owners already have full access - it's about making the membership view say one true thing about who has access.

So what Worth a glance for product leads thinking about how sharing UIs should behave when the data model and the form fields don't agree.

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?