flaky test: TestSqlCatalog/TestConcurrentTableViewCollisionReturnsCatalogSentinel hits SQLITE_BUSY on ubuntu runners

`TestSqlCatalog/TestConcurrentTableViewCollisionReturnsCatalogSentinel` (added in #1489) failed twice in a row on `ubuntu-latest go1.26.1` in PR #1785, which doesn't touch `catalog/sql`:

- https://github.com/apache/iceberg-go/actions/runs/31633730340/job/94238711845
- https://github.com/apache/iceberg-go/actions/runs/31634501371/job/94241281404

Failure in both cases:

```
Error: Target error should be in err chain:
expected: "table already exists"
in chain: "failed to create view: database is locked (5) (SQLITE_BUSY)"
```

The test races a table create against a view create and expects the loser to get the `table already exists` catalog sentinel, but on ubuntu runners the losing writer sometimes hits SQLite's `SQLITE_BUSY` instead — the lock contention surfaces before the uniqueness check does. It passes consistently on macOS locally (10/10 with `-count=10`) and on the macOS CI jobs.

Possible fixes: set `_busy_timeout`/`_txlock=immediate` in the test DSN so the losing writer waits for the lock instead of erroring, or have the test also accept a retry-on-busy path. Happy to send a PR if maintainers have a preference.

Made with [Cursor](https://cursor.com)

Start with TestSqlCatalog/TestConcurrentTableViewCollisionReturnsCatalogSentinel in catalog/sql and inspect the test DSN and concurrent table/view creation. Run the targeted test repeatedly on an Ubuntu runner, then verify the losing writer no longer fails with SQLITE_BUSY and still produces the table-already-exists catalog sentinel.

Written by the indexing model from the issue text.