docs(prd): fix 3 schema inaccuracies in litigation-planner PRD

planck flagged via mai report feedback (id 12301) after the B5+B6
verification round caught them:

- §5.4 'INSERT into paliad.project_parties' → real table is paliad.parties
- §5.4 'status=open' → real CHECK constraint allows pending/completed/cancelled/waived
- §7.4 listed verfahrensablauf-detail-mode.ts as dead code, but builder
  imports filterByDetailMode from it; struck through with KEEP note.

Code shipped (B5+B6) used the correct values throughout; this aligns
the historical PRD with reality so a future reader doesn't repeat the
verification time planck spent.

docs/plans/prd-procedures-litigation-planner-2026-05-27.md

@@ -509,14 +509,14 @@ Helper function `paliad.can_see_scenario(scenario_id)` mirrors the existing `pal
   Transaction:
     1. INSERT into paliad.projects (carrying step-2 + step-3 payloads, + scenario notes)
        SET origin_scenario_id = <scenario.id>
-    2. INSERT into paliad.project_parties from step-2 payload
+    2. INSERT into paliad.parties from step-2 payload
     3. For each scenario_proceeding (depth-first, parent before child):
        a. INSERT scenario_flags as projects.scenario_flags (parent-level only;
           children become sub-projects via parent_project_id)
        b. For each filed scenario_event: INSERT paliad.deadlines row with
           status='done', completed_at=actual_date, audit_reason='via Litigation Builder promotion'
        c. For each planned scenario_event: INSERT paliad.deadlines row with
-          status='open', due_date=computed (or actual_date override)
+          status='pending', due_date=computed (or actual_date override)
        d. Skipped events: not inserted (no deadline row)
     4. UPDATE paliad.scenarios SET status='promoted', promoted_project_id=<new>
     5. Navigate to /projects/<new>
@@ -636,7 +636,7 @@ Dead code to delete (verify with grep before deletion):
 - `frontend/src/client/verfahrensablauf.ts` (replaced by builder.ts orchestration)
 - `frontend/src/client/views/verfahrensablauf-state.ts` (replaced by scenario-backed state)
 - `frontend/src/client/views/verfahrensablauf-state.test.ts`
-- `frontend/src/client/verfahrensablauf-detail-mode.ts` (replaced by per-triplet Detailgrad)
+- ~~`frontend/src/client/verfahrensablauf-detail-mode.ts`~~ — KEEP. Builder imports `filterByDetailMode` from it; per-triplet Detailgrad reuses this module.
 - Existing scratch tab content in `frontend/src/client/procedures.ts` (4-tab toggling logic, mode routing)
 
 **Kept**: