CLI: Fix --login option and "landingPage" Blueprint property

[adamziel]

Makes the --login flag work in Playground CLI.

When you start the CLI server for the second time on the same machine it shows the login screen instead of auto-logging you in. The culprit is the playground_auto_login_already_happened cookie, which the first run sets and later runs inherit. Because the cookie survives process restarts, the auto-login plugin silently skips its job. 

Solution

run-cli.ts now tracks whether a request is the very first one served by the process. On that first hit it:
• clears the stale cookie by returning a Set-Cookie header that expires it immediately, and
• responds with a 302 pointing to /, guaranteeing the request that follows will hit WordPress after the login routine runs.

The logic is guarded by a boolean isFirstRequest flag initialised at boot and flipped after the first response.

As a follow up, we'll need to also adjust how the landingPage property is handled (it collides with the hardcoded redirection to /)

CI adjustments

Because the very first HTTP call now yields a redirect, the workflow had to be taught to trigger—and then ignore—the 301/302 chain. The fix:
• primes the server with an initial curl so the redirect is consumed before the readiness probe starts
• replaces the Playground-CLI-based package host with a Python http.server to avoid using tool that's being tested in the test

How to verify

Run wp-playground server twice in a row. Each session should open directly in wp-admin without showing the login form. The CI matrix stays green.