test: cover /applauncher session creation from a session_template (cluster-backed)

Follow-up to #5850 (case 2), split out of #9465.

#9465 covered only case 4 of #5850 (missing required params). Case 2 is descoped there because of **fixture and capacity requirements**, not because of any client-side limitation. Filing it so the case stays tracked.

## What to test

Navigate to `/applauncher` **without** a `session_id` but with a `session_template`, and assert that a new session is created and the app launches.

## Prerequisites

- A configured session-template fixture (created in test setup or seeded).
- Agent capacity on a running Backend.AI cluster to actually start the session.
- The launch spec's existing guards (serial mode, no-agent / timeout skip) — see `e2e/app-launcher/app-launcher-launch.spec.ts`.

## Note on the sToken half

An sToken-authenticated variant of this flow is **not** achievable in-tree: the WebUI never validates an sToken. `packages/backend.ai-client/src/client.ts:1172` POSTs it verbatim to `/server/token-login`; the webserver (`web/server.py:682`) forwards it to `_authorize_via_anonymous_session`, and the manager (`services/auth/service.py:277-281`) hands it to an `AUTHORIZE` hook plugin that lives out of tree. Drive this case through a normal logged-in session instead (same approach as the case-1 follow-up).

## Related

- Parent issue: #5850
- Slice already merged/open: #9465
- Sibling follow-up (case 1, existing `session_id` fast path): #9488

Start with e2e/app-launcher/app-launcher-launch.spec.ts and its existing serial, no-agent, and timeout guards. Set up or seed a session-template fixture, use a normal logged-in session on a running Backend.AI cluster, and navigate to /applauncher without session_id but with session_template. Done means the test confirms a new session is created and the app launches.

Written by the indexing model from the issue text.