fix: hold a login unique in the database, not just in the application

[blaipr]

uk_User_01 covered (login, ssoLogin) rather than login. MySQL treats NULLs in a unique index as distinct, so two rows with the same login and no SSO login — which is most users — are both accepted:

INSERT ('alice', NULL)  -> ok
INSERT ('alice', NULL)  -> ok        <- two users called alice

The application's rule is not that one. checkDuplicatedOnAdd() refuses any login collision whatever the SSO login is:

UPPER(:login) = UPPER(login)
OR (UPPER(:ssoLogin) = UPPER(ssoLogin) AND ssoLogin IS NOT NULL AND ssoLogin <> '')
OR ...

But that is a SELECT followed by an INSERT, so two requests arriving together both find nothing and both insert, and the index is what has to stop the second. Two simultaneous first-time logins through createOnLogin() are enough — the same shape as the Client key in #806, and the pattern already recorded for Category/Client/Tag.

What makes it more than untidy: getByLogin() answers with LIMIT 1 and no ordering, so which of the two rows a login resolves to is the server's choice. DatabaseAuth is the caller.

ssoLogin is deliberately not covered

My first draft added UNIQUE(ssoLogin) for symmetry. That would have been a regression, and it is verified rather than reasoned:

• Filter::getString('') returns '', not null;
• the user form always submits login_sso, so a blank field stores '';
• '' is not distinct the way NULL is — two of them collide.

INSERT ('alice',''), ('bob','')  ->  ERROR 1062 Duplicate entry '' for key 'uk2'

So a unique index over ssoLogin would refuse the second user who has no SSO login at all. The application's own rule exempts the empty case for exactly this reason. usersWithNoSsoLoginDoNotCollideWithEachOther exists to rule the regression out.

Schema only

Following #806: which of two duplicate logins is the real person, and what becomes of the accounts the other owns, is an administrator's decision rather than a migration's. A fresh install now gets the constraint.

Tests

• SchemaEnforcesIdentityTest::aLoginIsHeldUniqueOnItsOwn reads the shipped schema — a composite key over (login, ssoLogin) does not satisfy it.
• LoginIsUniqueTest builds the User table from dbstructure.sql itself on a real server and inserts the duplicate. Restoring the composite key fails it with Failed asserting that exception of type "PDOException" is thrown — the duplicate insert simply succeeds, which is the defect.

3974 unit + 976 integration pass; PHPStan level 6 on src and PHPCS clean.