[A2wkiller]

Fixes #785.

What

59 files in server/tests opened a database pool and never gave it back. bun test runs every file in one process, and a pool opens its connections on first use and holds them until it is closed, so the leaks accumulated for the whole run against PostgreSQL's max_connections of 100. When the ceiling goes, the failure (sorry, too many clients already) lands on whoever adds the next file, not on the file that leaked - which is exactly what #770's CI run showed.

Change

• Close the remaining files. Each of the 59 files closes its pool in an afterAll registered last, so Bun's first-registered-first ordering runs it after the file's own cleanup - the idiom the already-closing files use.
• A guard test (server/tests/database-pool-closing.test.ts) refuses a new file that opens a database without closing it. A guard rather than a lint rule because "opens and closes" is a pairing, and server/tests is outside tsc, so types would not catch it either.
• The sharded runner's header now says what the ceiling actually is: a function of how many files have run, not of how many have been imported (a pool opens its connections on first query, not at construction). Sharding stays for wall-clock, not as the only thing between the suite and the ceiling.

Tests

Measured against PostgreSQL 14 with all 59 files in one process:

• Peak connection count: 83 before, 4 after
• 758 tests pass either way (the leak is a ceiling margin, not a correctness bug, until the day it crosses 100)

The 5 files with nested afterAll cleanup (plugin-store, enterprise-controls, shared-use-store, plugin-credential-binding, sandboxed-components) pass with their cleanups running before the close. Biome lint clean on all 61 changed files.

Prepared with AI assistance (Instinct); tested as noted above.