[v3] feat: accept a password for a named bot in createPlayer

[monikon22]

Closes the direction we settled on in #58: no account store, just the one gap that was real.

createPlayer({ password })

A bot the test names bypasses the pool (test-runner.ts, const pool = options?.username ? null : ...), and syntheticAccount() never set a password, so an auth plugin had nothing to log it in with. The only way out was auth-authme's plugin-wide password option, which is a plain value and its own doc limits to a throwaway local server.

The password now threads createPlayer → connect → syntheticAccount. Nothing else was needed: onPlayerCreate already ignores account.justCreated and answers whichever prompt actually arrives, so a name the server knows gets /login and a fresh one gets /register.

const friend = await createPlayer({
    username: 'FriendBot',
    password: process.env.FRIEND_BOT_PASSWORD,
});

A password with no username, in an environment that has a pool, throws — a pooled account carries its own, so the passed one would have gone nowhere.

multi-bot and Cross-bot off excludeTests

This is the correction from the issue thread. Neither test needs the name FriendBot; they need a second bot. createPlayer() with no username already leases one from the pool, so dropping the name is the whole fix and both tests now run on the stand.

Docs

createPlayer() in the API reference gets its options, and the "an explicitly named bot bypasses the pool" paragraph in external-servers now says to pass the password with the name and to read it from the environment rather than writing it in the spec.

Checked

tsc --noEmit clean in runner-package and in the example's e2e sources. The stand suite needs a running server, so the two un-excluded tests are for CI to confirm.