Drop legacy status handling from the V2 transformer

[Aloento]

Changes

The backend now emits canonical status values only (analyzing -> analysing, in progress -> in_progress, scheduled -> planned, SYSTEM folded to resolved/completed when an end date is present) and no longer sends description rows in updates[]. The frontend handling for those legacy values is therefore dead code and is removed:

• Status.Entities.ts: remove legacy StatusEnum members Analyzing, Description, InProgressLegacy, Scheduled, System and the accompanying comment block. All canonical members and EventEntityV2.description are kept.
• Status.Trans.V2.ts: remove the matching case branches in ResolveEventStatus and the description workaround in the updates loop. The shouldInferStatusFromUpdates inference path and the Changed/ImpactChanged -> prev semantics are unchanged.

No behavior, UI, or dependency changes.

Verification

• npm run build (vite build, with dummy SD_* env vars): passes
• npm run lint (eslint): passes
• npx vitest run: no test files exist in the repo; vitest is not installed as a dependency, so the suite cannot run (pre-existing, unrelated to this change)
• npx tsc --noEmit: not applicable — TypeScript is not a project dependency and the build does not type-check (pre-existing)

[ecosquad-autoreview]

Summary

Deletion-only cleanup removing the legacy StatusEnum members (System, Analyzing, Description, InProgressLegacy, Scheduled) and their matching branches in ResolveEventStatus / the updates loop in TransformerV2, on the premise that the backend now only emits canonical values and no longer sends description rows in updates[].

I verified:

• No remaining references to the removed enum members anywhere in the codebase (grep for StatusEnum.System|Analyzing|Description|InProgressLegacy|Scheduled returns nothing). Enums.ts (GetStatusString), EventApprove.tsx, and useEditForm.tsx all use only canonical members.
• The removed endDate parameter was only used by the removed StatusEnum.System branch; no other branch needed it. Callers updated consistently (both ResolveEventStatus call sites in Status.Trans.V2.ts).
• IsIncident import in Status.Trans.V2.ts is still used (initial status and the "completed past end date" check at the bottom of the loop), so no dangling import.
• Changed/ImpactChanged -> prev semantics and the shouldInferStatusFromUpdates path are untouched, as stated.

Findings

Suggestion — Status.Entities.ts, EventEntityV2.description (line 41)
The PR description says the backend no longer sends description (only updates[] rows), yet EventEntityV2.description is kept and dbEvent.Description = event.description in TransformerV2 still reads it. If the field is truly gone from the API payload this is dead code too and could be removed; if it's still sent at the event level, that contradicts the description. Worth confirming which is correct.

Suggestion — coupling on backend contract
The safety of this deletion depends entirely on the backend change being deployed before/with this frontend. If an older backend still emits SYSTEM rows, they now fall through to default: return undefined (Status.Trans.V2.ts line 60) and the event silently keeps its default status instead of being folded to Resolved/Completed. Presumably acceptable given the backend ships first, but flagging in case rollbacks could cross the version boundary.

Information — CI
CI checks are still in progress (check, CodeQL) at review time; I could not judge the build/test result. The author reports vite build and eslint pass; there are no tests in the repo (pre-existing).

No correctness, security, or performance issues found. The change is small, consistent, and self-contained.