State machine for statuses

[bakhterets]

fix: state machine validation for maintenance event status transitions

Problem

Maintenance events allowed arbitrary status changes — any status could be set to any other, bypassing the expected lifecycle. This made it possible to, for example, jump from pending_review directly to in_progress, or re-open a cancelled event.

Solution

Introduced a state machine in internal/event/event.go that enforces valid status transitions per event type (maintenance, incident, information).

Maintenance lifecycle (enforced transitions):

pending_review → reviewed, cancelled
reviewed → planned, cancelled
planned → in_progress, cancelled
in_progress → modified, completed, cancelled
modified → in_progress, completed, cancelled

Special cases:

• pending_review → pending_review is allowed — creators can update the message without changing status
• Empty current status is accepted (legacy data / test compatibility)

Incident and information events allow any valid status of their type (existing permissive behaviour preserved).

Changes

File	Change
internal/event/event.go	IsValidTransition() + per-type transition validators
internal/api/v2/v2.go	Call IsValidTransition on PATCH; return 400 on invalid transition
internal/api/errors/incident.go	ErrInvalidStateTransition, ErrIncidentPatchStatusAlreadySet
docs/auth/permissions.md, rbac.md	Updated permission matrix to reflect new transition rules
tests/	Tests extended to cover invalid transitions and state machine edge cases

HTTP behaviour

• Valid transition → proceeds normally
• Invalid transition → 400 Bad Request with ErrInvalidStateTransition

Testing

New test cases added in v2_events_test.go, v2_test.go, and v2_system_incident_test.go covering boundary transitions and self-transitions.