perf: increase bridge pool cache size limit (#21399)

With this low upper bound, the cache thrashes under load (i.e. cache
entries are replaced too quickly), leading to audit records not
persisting in time before the context is canceled (see `OnEvict`
behaviour).

The TTL remains 15m because we need to keep MCP connections relatively
fresh, but this TTL is irrelevant if injected tools are not used.

This was an oversight; the limit should never have been set so low. 5000
is likely so large that the cache will never fill up; in future we
should make this configurable if customers run into issues. It's a bit
difficult right now to determine how much real memory each element
_actually_ uses, but even if it's a crazy number like 100KiB per
instance then it'll only use 500MiB.

Signed-off-by: Danny Kopping <danny@coder.com>

enterprise/aibridged/pool.go

@@ -41,7 +41,7 @@ type PoolOptions struct {
 	TTL      time.Duration
 }
 
-var DefaultPoolOptions = PoolOptions{MaxItems: 100, TTL: time.Minute * 15}
+var DefaultPoolOptions = PoolOptions{MaxItems: 5000, TTL: time.Minute * 15}
 
 var _ Pooler = &CachedBridgePool{}