Ban from app screen

[Yasminekoulam]

What was done

Added a new screen that is displayed when a user gets banned from the app.

Problem

When a user was banned, unbanned, logged back in, and then banned again,
the ban screen was not appearing despite the WebSocket message being
received correctly.

Two root causes were identified:

1. ref.listen inside build is tied to the widget rebuild cycle.
   If MainShell was not rebuilding at the moment the ban event arrived,
   the listener was silently skipped.

2. banProvider is keepAlive: true, meaning its state persisted across
   sessions. After the first ban, state was true. On re-login, when a
   new ban event arrived, Riverpod saw true → true and did not notify
   the listener.

Fix

• Replaced ref.listen in build with ref.listenManual in initState,
  which is independent of the build cycle and stays active as long as
  the widget is mounted.
• Added state = false at the start of startListening() to force a
  reset on every new session, ensuring Riverpod always sees a false → true
  transition when a ban event arrives.

Note on string matching at login

so the leader flagged contains('banned') as fragile. This is acknowledged,
but it is currently the only viable approach given the backend constraint:

POST /api/v1/auth/login returns HTTP 401 for both wrong credentials
and banned accounts. The only difference is the response message:

• Wrong password → "Invalid Credentials"
• Banned account → "You are banned from using this application"

The backend (TokenService.login) throws the same Unauthorized exception
in both cases, handled by GlobalExceptionHandler which maps it to a
generic 401 with no dedicated error code or field.

The clean fix would be for the backend to return a distinct HTTP status or a structured error field ({"code": "ACCOUNT_BANNED"})
for banned accounts. Until that backend change is made, string matching
is the only way to differentiate the two cases on the client side.