Show per-node resource allocatability warning in session launcher before submission

## Background

In clusters with mixed CPU-only and CPU+GPU workloads, users see idle GPUs in the resource summary yet their multi-node sessions go into pending due to per-node CPU shortage. The current session launcher only checks aggregate remaining resources (keypair / group / scaling group totals), so it can show "resources available" even when no single node has enough CPU to satisfy the per-node request.

BA-6562 adds a `check-allocatability` API (POST `/v2/resource-allocation/check-allocatability`) that evaluates per-node fit and returns which resource slots are insufficient per agent, ordered by scarcity (accelerators first). This issue tracks the FE response to that API.

**Context thread:** Teams - UX Ideas, References, and Questions (2026-06-18)

## Problem Breakdown

Two distinct failure modes users currently cannot distinguish:

**Case 1 - Total capacity exceeded**

- Root cause: Aggregate remaining < requested across keypair / group / scaling group
- Current UX: Slider warning already shown (existing behavior)

**Case 2 - Per-node fit failure** (new)

- Root cause: Aggregate total is OK, but no single node has enough of one resource slot
- Current UX: No warning shown — session silently goes PENDING after creation

This issue addresses Case 2.

## Candidate Approaches

### Option A - Real-time per-node check on slider change

Call `check-allocatability` on every resource value change, debounced (~500 ms). Show per-resource slot warnings below the relevant slider.

**Pros:** Immediate feedback while adjusting; user sees impact of each slider move in real time.

**Cons:** Frequent API calls even when user is still mid-adjustment; cluster state changes every second so warnings may flicker; debounce/throttle complexity on both client and server.

### Option B - Pre-submit check (single call on Create button)

Call `check-allocatability` once when the user clicks the Create / Launch button, before submitting to the scheduler queue. Keep the form open and show an inline alert if the check fails.

Two actions in the alert: **[Adjust resources]** (dismiss, stay on form) / **[Create anyway]** (submit regardless).

**Pros:** Single API call per attempt; snapshot is taken at the most meaningful moment; no flicker; form stays open so user can adjust immediately.

**Cons:** User must click Create once before learning about the issue.

### Option C - Hybrid (rough check on slider + accurate check on submit)

Keep existing total-capacity slider warnings as-is (fast, already implemented). Add the per-node `check-allocatability` call only at submit time (Option B). The two signals serve different purposes and do not conflict.

**Pros:** Best of both; no new noise on sliders; accurate gate at submission.

**Cons:** Two warning systems to maintain; users may be confused by different warning levels.

### Option D - Improve pending status message only (no pre-check)

Skip the pre-check entirely. Instead, surface the insufficient resource slot information in the session status / pending reason message that already appears after creation. The backend scheduler already attaches insufficient-slot metadata to the pending reason; the FE just needs to parse and display it.

**Pros:** Minimal scope; no new API call needed; improves experience for users who intentionally create pending sessions.

**Cons:** Feedback comes after creation, not before; user must create, observe, cancel, and recreate - more friction for the immediate-execution case.

### Option E - Combine B + D

Run the pre-submit check (Option B) AND improve the pending status message (Option D). Users who skip or dismiss the warning still get clear information in the pending state.

## Open Questions

1. Which option(s) best balance UX quality vs implementation cost?
1. For Option A/B/C: should the check be skipped when the user already intends to create a pending session (e.g., explicit "allow pending" toggle)?
1. For the cluster-size control: should fitting node count (`per_agent.filter(fits).length`) replace the current total-capacity-based `maxImmediateClusterSize`, or supplement it?
1. Policy-based limits (keypair / group quotas) are out of scope for BA-6562 - how do we communicate to users that even a passing per-node check does not guarantee immediate execution?

## Dependencies

- Blocked by BA-6562 (per-node check API + GraphQL field + Client SDK v2)

JIRA Issue: FR-3176

The issue names the session launcher, Create/Launch flow, existing aggregate slider warnings, and pending-status messaging, but no files or tests. First read those existing frontend paths and confirm the BA-6562 API and GraphQL contract. Resolve the listed UX options and open questions before implementation; done means the chosen behavior is implemented and verified for per-node resource failures.

Written by the indexing model from the issue text.