Take the terminal's role from the back office, not from which tab was clicked

The role split was right; only its source was wrong. Signing in matched what
was typed against two constants compiled into the app — admin@nearle.in and
cashier@nearle.in — so which shell a person got was a property of the *build*.
A shop could not add a third person, revoke either of the two it had, or stop
anyone with the APK reading both passwords out of it.

TerminalLogin survives unchanged in shape, because the shape was the good part:
one flag the shell reads, a session that decides it, and a cashier sign-out that
takes the catalogue with it while a supervisor's leaves it behind. Every
consumer — visibleModulesProvider, resolvedModuleProvider, the sidebar, the page
header, the sign-out dialog — is untouched. What changed is that the enum is now
only constructible from a session the back office signed, so there is no path
left where the terminal grants itself a permission the server did not send.

It reads `can_manage_staff` rather than the role name or id. app_roles holds six
rows for four distinct roles, a great many accounts carry a roleid that is not
in the table at all, and the name comes back blank for most of them. Matching on
either would mean shipping a copy of the role table in the app and keeping the
two in step for ever. One boolean, decided server-side, cannot drift. It
defaults to false, which matters on the restore path: a session saved by a build
that predates the field comes back as a cashier, never silently as an admin.

This also restores the sign-in layer itself — pos_auth_api, pos_session,
session_store, the staff import and the bearer token — which an earlier commit
removed wholesale from a stale checkout. Its parent was the commit that added
them, so the deletion was a bad merge rather than a decision; the terminal has
been running on the two constants since.

The login screen loses its role tabs and its credential prefill. You do not
choose what you are on the way in.

The opener is now matched on the back office user id rather than on the first
account with a matching role, so the first bill of a shift is attributed to
whoever actually signed in.

Tests: the smoke suite pinned only the supervisor shell, and it was passing for
the wrong reason — the fake session omitted can_manage_staff, and the sidebar it
asserted on was there because the role was hardcoded. Both halves are pinned now
and the fake is parameterised. widget_test.dart was the stock Flutter counter
template, restored by the same bad merge, testing a MyApp that has never existed
in this repo.

292 tests pass; analyzer reports no errors and no warnings.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

lib/data/remote/pos_auth_api.dart

@@ -0,0 +1,149 @@
+import 'dart:async';
+import 'dart:convert';
+
+import 'package:http/http.dart' as http;
+
+import '../../domain/entities/pos_session.dart';
+
+/// Raised when the back office refuses or cannot answer a sign-in.
+///
+/// Carries a message meant to be shown to whoever is standing at the till, so
+/// it is written for them rather than for a log: what happened, and what they
+/// can do about it.
+class PosAuthException implements Exception {
+  const PosAuthException(this.message, {this.isCredentialFailure = false});
+
+  final String message;
+
+  /// Whether the details were wrong, as opposed to the back office being
+  /// unreachable. The till reacts differently: a bad password is worth
+  /// re-typing, an unreachable server is worth waiting for.
+  final bool isCredentialFailure;
+
+  @override
+  String toString() => message;
+}
+
+/// Signs a terminal in against the back office.
+///
+/// Talks to the same `app_users` accounts as the web console, so a manager who
+/// can open the back office can open the till with the same details — one
+/// account store means deactivating a leaver closes both doors at once.
+///
+/// ```
+/// POST {base}/login
+/// { "authname": "…", "password": "…", "terminal_id": "T5EDD" }
+/// ```
+///
+/// answered with `{ code, status, details: { token, store_id, locations, … } }`.
+class PosAuthApi {
+  PosAuthApi({required this.baseUrl, http.Client? client})
+      : _client = client ?? http.Client();
+
+  final String baseUrl;
+  final http.Client _client;
+
+  /// Generous, because this runs on a shop's connection while somebody watches.
+  /// Short enough that a dead endpoint is reported rather than hung on.
+  static const _timeout = Duration(seconds: 20);
+
+  /// Exchanges credentials for a session.
+  ///
+  /// [locationId] is only meaningful for an account entitled to several
+  /// outlets: it says which one this terminal is standing in. It is a request,
+  /// not an assertion — the back office checks it against what the account may
+  /// actually reach, and that check is the whole point of the endpoint.
+  Future<PosSession> login({
+    required String authname,
+    required String password,
+    String? terminalId,
+    String? deviceId,
+    int? locationId,
+    int? configId,
+  }) async {
+    if (baseUrl.isEmpty) {
+      throw const PosAuthException(
+        'This terminal has no back office configured. Set the endpoint in '
+        'Settings → Connectivity & sync.',
+      );
+    }
+
+    final body = <String, Object?>{
+      'authname': authname.trim(),
+      'password': password,
+      if (terminalId != null && terminalId.isNotEmpty) 'terminal_id': terminalId,
+      if (deviceId != null && deviceId.isNotEmpty) 'device_id': deviceId,
+      if (locationId != null && locationId > 0) 'location_id': locationId,
+      // Sent only when known. The backend infers it when absent, and a shop
+      // has no way to find out what its configid is.
+      if (configId != null && configId > 0) 'configid': configId,
+    };
+
+    final http.Response response;
+    try {
+      response = await _client
+          .post(
+            Uri.parse('$baseUrl/login'),
+            headers: const {'Content-Type': 'application/json'},
+            body: jsonEncode(body),
+          )
+          .timeout(_timeout);
+    } on TimeoutException {
+      throw const PosAuthException(
+        'The back office did not answer in time. Check the connection and try '
+        'again.',
+      );
+    } on Object {
+      throw const PosAuthException(
+        'Could not reach the back office. Check the connection and try again.',
+      );
+    }
+
+    Map<String, Object?> decoded;
+    try {
+      decoded = jsonDecode(response.body) as Map<String, Object?>;
+    } on Object {
+      throw PosAuthException(
+        'The back office answered with something this terminal could not read '
+        '(HTTP ${response.statusCode}).',
+      );
+    }
+
+    if (response.statusCode != 200) {
+      throw PosAuthException(
+        (decoded['message'] as String?) ??
+            'Sign-in was refused (HTTP ${response.statusCode}).',
+        // 401 is a wrong email or password; 403 is a real account that may not
+        // open this till. Only the first is worth re-typing.
+        isCredentialFailure: response.statusCode == 401,
+      );
+    }
+
+    final details = decoded['details'];
+    if (details is! Map<String, Object?>) {
+      throw const PosAuthException(
+        'The back office accepted the sign-in but returned no session.',
+      );
+    }
+
+    final session = PosSession.fromJson(details);
+
+    // A session with no token cannot authenticate anything, and one with no
+    // outlet cannot bill. Refused here rather than being saved and failing
+    // later against every request, which would be much harder to diagnose.
+    if (session.token.isEmpty) {
+      throw const PosAuthException(
+        'The back office returned a session with no token.',
+      );
+    }
+    if (session.locationId <= 0) {
+      throw const PosAuthException(
+        'This account is not attached to an outlet, so it cannot open a till.',
+      );
+    }
+
+    return session;
+  }
+
+  void dispose() => _client.close();
+}