tests: Postgres role cleanup fails silently, leaking test_user_* roles on shared test instances

`setUpDatabase` in [tests/tool.go:2801](https://github.com/googleapis/mcp-toolbox/blob/main/tests/tool.go#L2801) has cleanup, but throws away its errors:

```go
return func() {
_, _ = pool.Exec(ctx, fmt.Sprintf("DROP DATABASE IF EXISTS %s;", dbName))
_, _ = pool.Exec(ctx, fmt.Sprintf("DROP ROLE IF EXISTS %s;", dbOwner))
}
```

When `DROP DATABASE` fails, the role still owns that database, so the `DROP ROLE` behind it fails too. Both errors are discarded, so the test passes and the role stays.

**Leftovers today**

- `alloydb-pg-testing`: 41 `test_user_`
- `cloud-sql-pg-testing`: 9 `test_user_`, 1 `test_role_super_`

```
gcloud alloydb users list --cluster=alloydb-pg-testing --region=us-central1 --project=toolbox-testing-438616
gcloud sql users list --instance=cloud-sql-pg-testing --project=toolbox-testing-438616
```

Cleanup usually works, so this is a slow drip rather than a leak on every run: ~41 roles since the test landed in #2030 (Dec 2025). Each run creates two roles, so the odd count means sometimes only one of the pair survives. The leaked `test_role_super_*` suggests `setupPostgresRoles` has the same gap.

**Why it matters**

`list_roles`, `list_users`, and `list_database_stats` all read this list, so their output on these instances is now mostly UUIDs. That is noise in integration tests and unscoreable in evals: an agent asked "who has access to this database?" gets 41 lines of junk.

**Suggested fix**

1. `DROP DATABASE IF EXISTS ... WITH (FORCE)`, so a lingering connection does not block it.
2. Check the errors and fail the test, instead of `_, _ =`.
3. One-off cleanup of the roles already there.

Found while adding `alloydb-postgres` evals. Not blocking that work.