fix(lakekeeper): drop database when admin is not the owner

[benben]

Follow-up to #649. The drop wired in there hit a real-world ownership
mismatch in mw-dev:

```
drop database lakekeeper_ben_ext_ice: ERROR: must be owner of
database lakekeeper_ben_ext_ice (SQLSTATE 42501)
drop role lakekeeper_ben_ext_ice: ERROR: role
"lakekeeper_ben_ext_ice" cannot be dropped because some objects
depend on it (SQLSTATE 2BP01)
```

`EnsureRole` hands ownership to the per-tenant role
(`ALTER DATABASE OWNER TO ` + `ALTER SCHEMA public OWNER TO`),
so the `lakekeeper_` DB is owned by the tenant, not by the
admin. On shared RDS (external metadata case), the admin is a
non-superuser tenant of the shared cluster
(`ducklingexample`), so:

• `DROP DATABASE` fails with 42501 (must be owner).
• The follow-up `DROP ROLE` fails with 2BP01 because the role
  still owns the database.

Fix

DropDatabase:

• probe `pg_database`; no-op if absent
• look up the current owner, `GRANT` it to `CURRENT_USER`, then
  `ALTER DATABASE OWNER TO CURRENT_USER` before `DROP DATABASE`
• `GRANT` + `ALTER OWNER` are best-effort so the path stays correct
  when the admin is already the owner or is a superuser

DropRole:

• probe `pg_roles`; no-op if absent
• `GRANT` the role to `CURRENT_USER` so `REASSIGN OWNED` +
  `DROP OWNED` can run on shared RDS (PG14+ requires role-membership)
• `REASSIGN OWNED` first (handles owned database objects), then
  `DROP OWNED CASCADE` (cluster-wide grants + default privileges),
  then `DROP ROLE`. The first two are best-effort; only the final
  `DROP ROLE` failure is returned

🤖 Generated with Claude Code