Connect the Slack socket before walking the user directory

[ReganBell]

Why

startSlackPlugin fetched the full users.list snapshot before opening the socket. The @slack/web-api client pauses its whole request queue on a 429, so a rate limit anywhere on that client stalled the connection. Under the background ownership protocol the controller marks a replica ready only after its Slack runtimes have reconciled, so the stall also held back the whole cohort's readiness and, in a blue/green deployment, the promotion behind it. Observed on a production cohort: containers listening, then several minutes of silence, then the Slack connection and readiness arriving together.

What

• The plugin now connects first and warms the user directory in the background. getUserSnapshot is a cache with in-flight dedupe that classifyUserCached and the directory sync already load lazily, and its refresh already swallows errors, so nothing observable changes except that startup no longer waits for the walk.
• The identity-mode probe keeps running before the connection: it decides how principals are keyed and must not be guessed.
• The integration fixture waits for the background warm-up before tests inspect the published directory, and a new test pins the order: the socket is started before the first users.list page is requested, and the walk still completes.

Verification

node --test test/slack-index.integration.test.ts test/slack-runtime.test.ts test/background-controller.test.ts test/group-dm-open.test.ts passes (93 tests), tsc --noEmit and eslint clean on the changed files.