sql: DROP OWNED BY should remove default privileges

There is a behavior difference between Postgres and CRDB regarding how DROP OWNED BY interacts with default privileges.

In Postgres, running DROP OWNED BY will clean up any default privileges associated with the role. This allows the role to be dropped without errors:
```
postgres=# CREATE USER test_user1;
CREATE ROLE

postgres=# ALTER DEFAULT PRIVILEGES FOR ROLE test_user1 GRANT ALL ON TABLES TO public;
ALTER DEFAULT PRIVILEGES

postgres=# DROP OWNED BY test_user1;
DROP OWNED

postgres=# DROP USER test_user1;
DROP ROLE
```

In CRDB, the same sequence fails:
```
> CREATE USER test_user1;
CREATE ROLE

> ALTER DEFAULT PRIVILEGES FOR ROLE test_user1 GRANT ALL ON TABLES TO public;
ALTER DEFAULT PRIVILEGES

> DROP OWNED BY test_user1;
DROP OWNED BY

> DROP USER test_user1;
ERROR: role test_user1 cannot be dropped because some objects depend on it
owner of default privileges on new relations belonging to role test_user1 in database movr
SQLSTATE: 2BP01
```

According to the [PostgreSQL docs](https://www.postgresql.org/docs/current/sql-alterdefaultprivileges.html):

> If you wish to drop a role for which the default privileges have been altered, it is necessary to reverse the changes in its default privileges or use DROP OWNED BY to get rid of the default privileges entry for the role.

This issue is opened to update CRDB's DROP OWNED BY behavior to also remove any default privileges owned by the target role, matching PostgreSQL semantics.

Jira issue: CRDB-53266

Epic CRDB-60816

Start by reproducing the reported CREATE USER, ALTER DEFAULT PRIVILEGES, DROP OWNED BY, and DROP USER sequence, then trace the DROP OWNED BY entry point and default-privileges handling. Done means the role can be dropped after DROP OWNED BY, matching the PostgreSQL behavior, with a regression test covering the sequence.

Written by the indexing model from the issue text.