CI: server-hosting-type E2E (in-runner, no cloud) + cypress wizard

[adrians5j]

Follow-up from #5453 / #5429. Add an E2E for the self-hosted server hosting type, mirroring the AWS /e2e flow (.github/workflows/pullRequestsCommandE2e.yml) but running entirely in the GitHub runner.

Why it's simpler than the AWS E2E

Server flavour = SQLite + single Node process. No cloud → no AWS creds, no Pulumi backend, no OpenSearch secrets, no per-storage matrix, no teardown. Everything runs in ubuntu-latest.

Shape

1. Reuse the existing scaffold half: publish packages to Verdaccio → create-webiny-project ... --template-options '{"hostingType":"server"}' (the new CWP prompt → server/sqlite).
2. Instead of webiny deploy → run the server in-runner. Prefer building the deploy ARTIFACT and running it (validates feat(build): self-contained deployable server build (#5429) #5453): webiny-server build → run build/start.mjs (api) in the background + serve the admin build; wait-on the api. (Alternatively webiny-server serve tests the dev/serve path.)
3. Cypress adminInstallation wizard against localhost — same spec as AWS.

Placement

Likely a SEPARATE workflow (serverE2e.wac.ts) rather than a leg in the AWS matrix — shares the scaffold pattern but none of the AWS job env/Pulumi. Or add a "Server" row to the /e2e PR-comment table.

Nice-to-have

Once the server WebSockets runtime issue is fixed, a cypress assertion on a live notification (upload image → AI tags appear without reload) would exercise bg-tasks + scheduler + WS together — a strong server-specific check.

Notes

• Test secrets baked as build params are fine here (throwaway project).
• Build in the Linux runner → native binaries (sharp, better-sqlite3) match by construction.

Related: #5453, #5429.