UI for the preemption feature

## Background

WebUI follow-up based on [BA-3056](https://lablup.atlassian.net/browse/BA-3056) (BEP-1014, Done): when a pending session can't be placed due to insufficient resources, the scheduler can pick a lower-`jobPriority` **running** session owned by the **same user** as a victim, clear it, and let the pending session claim the freed slot. This issue covers the **session-owner-facing** UI for that feature. The companion **admin-facing** UI (per-resource-group preemption policy) is tracked separately in FR-3240.

## GraphQL surface already available (confirmed in `data/schema.graphql`)

- **Session creation** (`EnqueueSessionInput`):
- `jobPriority: Int! = 0` — scope-local preemption priority among the requester's own sessions only. Higher-`jobPriority` pending sessions can preempt lower-`jobPriority` running sessions of the **same** user; equal priority is never preempted.
- `isPreemptible: Boolean! = true` — per-session opt-out switch.
- **Session read** (`SessionV2Node`): `isPreemptible: Boolean!` already exposed for display.
- **Session status** (`SessionV2Status` enum): `PENDING`, `SCHEDULED`, `PREPARING`, `PREPARED`, `CREATING`, `RUNNING`, `DEPRIORITIZING`, `PREEMPTED`, `RESCHEDULING`, `TERMINATING`, `TERMINATED`, `CANCELLED`.
- Note: the scheduler's internal `RESERVED` soft-reservation stage (used to hold a slot for a pending session while its victim is cleared) is **not** a distinct GraphQL status — it is exposed as `SCHEDULED`. No separate UI state is needed for it.

## Scope

1. **Session launcher (create session)**
- Add optional "preemption priority" (`jobPriority`, default 0) and "allow this session to be preempted" (`isPreemptible`, default ON) controls — likely under an existing "Advanced options" section, separate from the unrelated global-queue `priority` field.
- Copy must make clear `jobPriority` only ranks a user's **own** sessions against each other — it is not a system-wide priority and has no effect unless the target resource group has preemption enabled (`PreemptionConfig.enabled`, see FR-3240). Consider hiding/disabling the controls when the selected resource group has preemption disabled, to avoid implying they do something they won't.

1. **Session list / detail — status handling**
- Add label / color / tooltip treatment for `PREEMPTED`, `RESCHEDULING`, `TERMINATING` (likely currently bucketed into a generic terminating/error look).
- When the resource group's preemption `mode = RESCHEDULE`, a preempted session cycles back to `PENDING` with its id/config/priority preserved — represent this as "rescheduled," not "failed."
- Consider a small badge/icon on the session list for `isPreemptible = false` sessions so owners can see at a glance which sessions are protected from preemption.

1. **Notification (needs backend confirmation before committing to it)**
- Whether a real-time toast/notification should fire when one of the user's own sessions gets preempted. Check whether a corresponding event/subscription exists; if not, mark as `TODO(needs-backend)` instead of building a polling workaround.

## v1 constraints — reflect in UX copy, don't over-promise

- **Same-user only.** A pending session can never preempt another user's session; cross-tenant preemption is an open BEP question and unimplemented.
- **Single-node trigger only.** A pending multi-node session cannot itself trigger preemption (a multi-node **victim**, once chosen, is evicted atomically across all its kernels).
- **`mode = RESCHEDULE` loses in-container state** for interactive sessions — this is an accepted, documented trade-off, currently an admin/resource-group-level setting rather than something the session owner chooses.

## Related

- FR-3240 — Admin Resource Group setting UI for `PreemptionConfig` (enabled / order / mode / preemptionMinRuntime).
- BA-3056 / BEP-1014 — backend epic and design doc.
- Recent backend hardening worth checking against the target manager version before wiring the UI: `jobPriority` exposure in the v2 API, an `isPreemptible`-not-persisted-on-create bug, and a resource-group preemption-config JSON-string storage bug were all fixed in recent backend changes.

## Acceptance criteria

- Session creation form exposes `jobPriority` + `isPreemptible` with clear, correctly-scoped copy.
- Session list/detail correctly render `PREEMPTED` / `RESCHEDULING` / `TERMINATING` with appropriate labels and tooltips.
- `bash scripts/verify.sh` passes.

JIRA Issue: FR-2312

[BA-3056]: https://lablup.atlassian.net/browse/BA-3056?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ