fix(win32): start clusters via pg_ctl so elevated shells can run

[Nabaatxaneh]

On Windows, postgres.exe refuses to start whenever the calling token is in the Administrators group (`Execution of PostgreSQL by a user with administrative permissions is not permitted''). Spawning postgres.exe directly therefore makes every elevated shell unable to start a cluster at all -- initialise() succeeds (initdb de-elevates internally) and only start() fails, which is confusing to diagnose.

pg_ctl is the binary Postgres ships for exactly this case: it builds a restricted token (get_restricted_token) and starts the postmaster under it. It is already exported by every platform package (including @embedded-postgres/windows-x64) -- it just was not used.

This change routes start()/stop() through pg_ctl on win32 only:

• start: pg_ctl -D -l /embedded-postgres.log -o '-p ' -w start, stdio ignored (the daemonised postmaster would otherwise hold a pipe open and keep the Node event loop alive; -w already blocks until connections are accepted and -l captures server output).
• stop: pg_ctl -D -m fast -w stop (pg_ctl exits after start, so there is no child handle for the taskkill path -- without this the server would leak).
• createDatabase/dropDatabase running-guards now also accept pg_ctl-started clusters.

Scoped to win32 so macOS/Linux CI keeps exercising the direct-spawn path. Proven in production: this is a source-level port of a patch carrying the same logic against 18.1.0-beta.16, under which embedded-Postgres integration suites execute in elevated Windows sessions for the first time (previously 0 ran), with no leaked postmasters.