SET SESSION AUTHORIZATION should use exact user@host matching instead of wildcard resolution

*Description:*

`SET SESSION AUTHORIZATION user@host` resolves the target using `find_user_or_anon()`, which performs wildcard host matching. This allows a non-existent user@host to silently resolve to a different account.

*Steps to reproduce:*

```
CREATE USER testuser@'%';
GRANT SELECT ON . TO testuser@'%';

– As a superuser:
SET SESSION AUTHORIZATION testuser@localhost;
SELECT user(), current_user();
```

*Expected:*
```
ERROR HY000: The user 'testuser'@'localhost' does not exist
```

*Actual:*
```
user() current_user()
testuser@localhost testuser@%
```

The session acquires the privileges of testuser@% even though testuser@localhost was specified and does not exist as an account.

*Analysis:*

`acl_setauthorization()` in `sql/sql_acl.cc` calls:
```
ACL_USER *acl_user= find_user_or_anon(user->host.str, user->user.str, user->host.str);
```

This applies the same wildcard/anonymous matching used during client connection. During connection, the host is derived from the network layer due to same the server implicitly validates the client's actual address. With `SET SESSION AUTHORIZATION`, the host is entirely user-supplied. A caller who knows `testuser@%` exists can specify any host value and the `%` wildcard will match, granting those privileges without the host-based access control that would apply during an actual connection.

This also causes functional issues. After wildcard resolution, `user()` reports the specified host (`testuser@localhost`) while `current_user()` reports the matched account (`testuser@%`).

While executing the command, the user explicitly asking to get privileges of a specific database user and in case that user not exists then it should through an error rather than granting privileges of related users. With SET SESSION AUTHORIZATION, the user explicitly specifies both username and host as input, expressing intent to assume a specific identity, so granting a different account's privileges through wildcard fallback violates that explicit intent.

*Proposed fix:*

Replace `find_user_or_anon()` with `find_user_exact()` in `acl_setauthorization()`:
```
ACL_USER *acl_user= find_user_exact(user->host, user->user);
```

If the caller wants `testuser@%`, they specify `SET SESSION AUTHORIZATION testuser@'%'` explicitly. No backward compatibility concern since this command was introduced in 12.0 and has no established user base relying on wildcard resolution.

NOTE:
The wildcard `%` means "this account can be matched when a client connects from any host" due to same the server resolves it based on where the client is actually connecting from. That's a server-side decision the user doesn't control. "SET SESSION AUTHORIZATION" is different - the user is explicitly naming which account they want. If they type testuser@localhost, they're asking for that specific account. If it doesn't exist, the command should fail rather than not silently giving them a different account's privileges.

No functionality is lost: if a user wants testuser@% privileges, they type SET SESSION AUTHORIZATION testuser@'%'. The wildcard still works for connections as before. We're only requesting change on how SET SESSION AUTHORIZATION resolves its input - from "guess the best match" to "use exactly what was specified".

This clearly differentiate connection establishment from the acquiring other user permission to improve the security context.