[Story]: Request to reorder onboarding steps

[adoLime]

User Story

As a User, I want to send a reorder request to my PM, so that I can flag a preferred order of my onboarding steps without editing the path myself.
As a PM, I want a clear inbox of pending reorder requests from my team members, so that I can accept or reject them with one click.

Context & Motivation

• Type: Functional (Onboarding — request workflow)
• Parent epic: 06 EPIC - Onboarding Journey & Digital Adoption #55 (06 EPIC – Onboarding Journey & Digital Adoption)
• Teams: team:backend (ReorderRequest entity + lifecycle + signal), team:frontend (User dialog + PM inbox / accept-reject UI)
• Related: [Feature]: Rework Onboarding Step #214 (step states — skipped / deactivated steps must behave correctly in the request flow), [Story]: Dashboard – onboarding-progress panel #195 / follow-up (PM onboarding dashboard — receives the signal), [Story]: Mark step done + progress indicator + OnboardingStep Rework #110 (progress must stay correct after the PM accepts a request).

Acceptance Criteria

• A User can open a "Request reorder" dialog on their own path view, drag the steps into a proposed order, and submit with an optional comment.
• The request is stored as a ReorderRequest with: id, user, path, proposed_order, optional comment, status ∈ {pending, accepted, rejected}, created_at, decided_at, decided_by, decision_comment.
• The pending request is visible to the PM assigned to that user's project (PM inbox / banner in the PM path view).
• The PM can accept (apply the proposed order — same effect as the PM-direct reorder from the sister story) or reject (with a short required comment).
• A rejected request is final — the User can submit a new one.
• The User can see the status of their own pending request and the decision comment.
• Reorder requests do not expose any chat content to the PM (refinement 2026-06-24: "der PM sieht sie auch nicht").
• The same audit and state-aware rules from the sister story apply on accept (progress preserved; deactivated steps stay deactivated; skipped steps require a confirm).
• Empty / loading / error states; i18n (en/de).

Sub-Tasks (by team)

• Backend — ReorderRequest entity + endpoints (create, list-for-PM, accept, reject); RBAC: only the assigned PM and Admins can decide; reuse the reorder-persistence + audit from the sister story; emit a non-chat signal to the PM dashboard.
• Frontend — User reorder-request dialog (DnD + comment); PM inbox / banner with pending requests; accept/reject UI with required rejection comment; user-facing status view.
• QA — tests for: User can request, only assigned PM can decide, accept applies the order, reject stores a comment, regular PM cannot see other projects' requests, no chat content leak.

Dependencies

• Sister story (blocks this one): PM/Admin direct reorder — needs the persist + audit + state-aware rules in place.
• [Story]: Onboarding checklist data model #109 (onboarding data model), [Feature]: Rework Onboarding Step #214 (step states), [Story]: RBAC with Admin / User separation #93 (RBAC), [Story]: Dashboard – onboarding-progress panel #195 or follow-up (PM onboarding dashboard panel — receives the signal).