[E06] Import Participants

I'm designing a multi-step screen flow for the EMS admin portal — a Spring
Boot + Angular SPA admin tool used by event operators (race directors)
to manage participants, events, and operational data. Visual language
matches existing portal screens you've designed in this project (C01, C03,
E01, E05) — JHipster 8 / Angular 16 / PrimeNG / ng-bootstrap stack;
match fonts, spacing, palette, density.

Design the **import flow**: an event organiser uploads a participants
CSV/XLSX, walks through a strict 2-phase mapping flow, watches an async
job run, and lands on a reconciliation summary. The flow spans two
use-case screens that must feel like one journey:

  E06 upload  →  C05 columns  →  C05 cells  →  C05 processing  →  E06 summary
   bookend         shared           shared        shared            bookend

The middle three steps (C05) are SHARED — the same screens are reused
later by E08 (result import) with no behaviour change, just different
caller key. Design accordingly: nothing in C05 may be EP-specific.

============================================================
[E06] Upload screen
============================================================

Single full-screen page with a right-rail "About this screen" panel
(see "Information panel pattern" below).

Main area:
- Page title: "Import participants — <event name>".
- File picker (CSV/XLSX) with drag-and-drop zone.
- One option: **Mode** — radio: `Overwrite` (default) | `Append`.
- "Recent imports" list below the picker — date, filename, row count,
  status. Clicking a row opens a read-only summary of that import (the
  same E06 summary screen, but for that uuid).
- Primary action: "Upload" (disabled until file picked).

On Upload click:
- POST /api/imports (multipart: file + mode).
- On 201 response, take the returned `uuid` and write
  `localStorage.setItem('importCaller:' + uuid, 'e06')`.
- Navigate to C05 at `/imports/{uuid}`.

============================================================
[C05] Mapping flow — shared 4-stage screen
============================================================

ONE full-screen page that progresses through 4 stages driven by the
backend state machine: COLUMN_MAPPING → CELL_MAPPING → PROCESSING →
COMPLETED/FAILED/CANCELLED.

Persistent UI on every stage:
- **Stage bar** — 4 pills at the top: Columns · Cells · Processing · Done.
  Current stage highlighted; prior stages marked complete; pills are
  READ-ONLY (not clickable). Forward-only flow; going back requires
  cancel + re-upload.
- **Right-rail "About this screen" information panel** — collapsible,
  default expanded, collapse state persisted in localStorage per screen.
  Content is STAGE-AWARE: different short purpose paragraph + bulleted
  operational details for each of the 4 stages.
- **Top-right** "Cancel import" button — DELETE /api/imports/{uuid},
  then redirect to caller's summary bookend (E06) with cancelled state.

Stage 1 — COLUMN_MAPPING
  Two-column layout:
  - Left: source CSV columns (header + first 3 sample rows for context).
  - Right: each source column's row showing what it maps to in the
    canonical schema. Three visual row states:
      • AUTO-MATCHED — quiet/grey treatment, target field shown,
        small `auto` tag, expandable to override.
      • USER-SET — neutral/strong treatment (no tag), target field shown.
      • NEEDS MAPPING — accent colour + required indicator, dropdown
        prominent.
    Operator's job is to scan auto-matched rows (the `auto` tag is the
    review affordance) and resolve any NEEDS MAPPING rows.
  - Primary action bottom-right: "Continue" — disabled while any row is
    NEEDS MAPPING. Calls PUT /api/imports/{uuid}/column-mappings.

Stage 2 — CELL_MAPPING
  List of unmatched FK values, grouped by FK type (e.g. "Category" group
  with the 3 unrecognised category strings beneath it). Each unmatched
  value gets a single filterable dropdown — ONE component reused across
  all FK types. Filter input auto-appears when the candidate list
  exceeds ~10 options; smaller lists render as a plain dropdown.
  Practical sizing: client-side filtering, hundreds of entries max.
  - Primary action: "Start import" — disabled until every unmatched FK
    is resolved. Calls PUT /api/imports/{uuid}/cell-mappings.

Stage 3 — PROCESSING
  Centred progress component:
  - Optional thin sub-stage label above the bar (hidden when the API
    returns no sub-stage). Designed for future API: `Validating → 15%
    → 47% → 84% → Summarising → Done`. v1 backend exposes only one
    PROCESSING state with a row-by-row counter, so the sub-stage label
    is hidden today — but the visual scaffolding is in place.
  - 0–100% progress bar.
  - "<rows processed> of <total> rows" counter.
  - Elapsed time.
  - "Cancel" button (DELETE /api/imports/{uuid}).
  - Polling cadence ~1s.

Stage 4 — Terminal (COMPLETED / FAILED / CANCELLED)
  IMMEDIATE redirect — no intermediate "Done" card.
  - Read `localStorage.getItem('importCaller:' + uuidFromRoute)`.
  - Remove that localStorage entry.
  - Navigate to the matching bookend's summary screen.
  - Fallback if caller key missing: navigate to `My imports` list.

State-error UX:
  - 409 on PUT /column-mappings or /cell-mappings — toast "This step has
    already been completed" + auto-refresh state via GET /api/imports/{uuid}.
  - Fatal job error — render the failure with reason + a "Try again"
    action that returns to the caller's upload screen.

============================================================
[E06] Summary screen — pure reconciliation view
============================================================

Operator arrives here from C05's terminal-state redirect. The job is
already in a terminal state — this screen does NOT poll, does NOT show
a progress bar, and never reverts to "in-flight" rendering.

On mount:
- Call GET /api/imports/{uuid}/results once.
- Render the reconciliation view.

Layout:
- Page header — "Import complete" (or "Import cancelled" / "Import
  failed"), filename, finished-at timestamp, "N rows processed" counter.
- Right-rail "About this screen" panel (same pattern as C05; copy
  describes what the summary represents and what to do next).
- Body: per-row reconciliation, in tabbed sections:
  - Created / updated counts.
  - Unresolved-person count + drill-down list.
  - FK-mismatch count + drill-down list (e.g. category not found).
- Bottom: "Open event participants" (links to E02) + "Import another
  file" (returns to E06 upload).

Failure-mode rendering:
- CANCELLED → header reads "Import cancelled" + the same per-row
  breakdown for whatever was processed before cancel.
- FAILED → header reads "Import failed" + reason + "Try again" returning
  to the upload screen.

============================================================
Information panel pattern (cross-cutting)
============================================================

Persistent collapsible right-rail panel ("About this screen") on every
full-screen step in this flow. Default expanded. Collapse state
persisted per-screen-key in localStorage. Content per screen:
- Short purpose paragraph (1–2 sentences explaining what THIS step is for).
- Bulleted operational details (the things an operator might be unsure
  about — what mode does, what `auto` means, what happens on cancel,
  etc).

Goal: train operators in-flow. They shouldn't need external docs to
complete an import.

============================================================
Output
============================================================

For each of the 5 screens (E06 upload, C05 columns, C05 cells, C05
processing, E06 summary):
- HTML/JSX + matching styles.
- Screen README that explains what it does and which API endpoints
  it consumes.
- Cross-screen README that explains:
  - The caller-key contract (per-uuid scoping, who writes, who reads,
    who removes, fallback).
  - The stage-ownership split (C05 owns processing; bookend owns summary).
  - How to reuse C05 unchanged when E08 (result import) becomes the
    caller — the only difference is the literal value written to the
    caller key (`'e06'` vs `'e08'`).

Continuing the EMS admin portal design language (E01, E05, C01, C03 you've
already designed). E06 is the bookend screen for participant CSV imports
— the page an operator lands on when they click "Import participants" from
an event's Control Centre.

Context: the import is async — we kick off a backend job, then poll for
progress, then show the result. E06 has 3 states a single screen flips
between:

State A — Pre-import: empty page with a big "Choose CSV" / drag-drop zone.
File picked → goes to C05 (shared mapping screen). Below the picker:
"Recent imports" list (5 most recent) showing date, filename, row count,
status. Clicking a row opens a read-only summary of that import.

State B — Active import: progress bar, current row counter (e.g. "2,341
of 8,452 rows processed"), elapsed time, and a live tail of "issues
discovered" — duplicate emails, ID Luhn check failures, missing required
fields, foreign-key resolution failures (unknown category, etc). Cancel
button. Issues tail is scrollable; shows row #, severity (warning/error),
and one-line description.

State C — Post-import summary: top stats (rows processed, succeeded,
warned, failed). Below: a tabbed view — "Errors" tab (rows that didn't
import + why), "Warnings" tab (rows that imported but with caveats),
"Imported" tab (success rows, with quick search). For errors, an inline
"Edit and retry" action that reopens just those rows for re-mapping.
Bottom: "Done" + "Import another file".

Screen must feel like a single page that morphs between states (no
full-page navigation). No leaving the URL during async work.

Style: same visual language as the existing portal designs (E01, E05).
Match colour palette and information density.

Output: HTML/JSX + styles, README explaining each state's transitions
and the data contract for the async progress feed (probably SSE or
WebSocket; backend is TBD but the UI should support both).