## ADDED Requirements

### Requirement: Authorization-state changes revoke stale login sessions
The system SHALL increment `auth_version` whenever a managed account's effective role, enabled status, or validated page-permission map changes. A token whose embedded version differs from the current account version MUST be rejected before a protected controller or service method executes.

#### Scenario: Promoted account uses an old token
- **WHEN** an active account is changed from a non-administrator role to `DEVELOPER` or `SUPER_ADMIN` while it still holds an earlier login token
- **THEN** its next protected request is rejected as requiring a fresh login, and a new login receives a token with the current role

#### Scenario: Permission map changes without a role change
- **WHEN** an administrator changes an account's validated page permissions or enabled status
- **THEN** the prior token is rejected on its next protected request and the account's next login uses the new effective permissions and status

#### Scenario: No-op account edit
- **WHEN** an administrator saves an account with the same effective role, status, and validated page permissions
- **THEN** the account's `auth_version` is unchanged and its current session remains valid

### Requirement: Protected write failures provide safe actionable categories
The system SHALL preserve generic authorization denial for a valid authenticated user without the required role or page permission. It SHALL return a login-required response for an invalidated or absent session, and a refresh-and-retry response for a missing or invalid CSRF token. Responses MUST NOT disclose token values, account existence, roles, or permission maps.

#### Scenario: Valid non-administrator creates an account
- **WHEN** a valid non-administrator token submits `POST /api/system-users`
- **THEN** the system returns a generic authorization-denied response and does not write an account row

#### Scenario: Browser omits CSRF input
- **WHEN** an authenticated browser sends a protected non-login write without a valid CSRF token
- **THEN** the system returns a safe refresh-and-retry response and does not execute the controller business method

### Requirement: Browser session state follows authentication failure
The shared browser request helper SHALL clear the in-memory authenticated user and navigate to the login route when a protected request returns 401. It MUST NOT automatically repeat the failed request. It SHALL request CSRF input again whenever the `XSRF-TOKEN` Cookie is absent for a protected non-login write.

#### Scenario: Authorization change invalidates the active browser session
- **WHEN** an already-open browser sends a protected request with a token invalidated by an authorization-state change
- **THEN** the browser clears its local identity, navigates to login, and does not retry the failed write

#### Scenario: CSRF Cookie is missing after prior initialization
- **WHEN** a protected browser write begins after the `XSRF-TOKEN` Cookie has been removed or expired
- **THEN** the client requests fresh CSRF input before sending the write
