Define typed error models for Vipps and BankID API failures

Use Dart's sealed class feature (available since Dart 3.0) for exhaustive pattern matching at compile time. Define the hierarchy in lib/src/auth/errors/auth_failure.dart (or equivalent path under the auth domain). Example structure: sealed class AuthFailure { const AuthFailure(); } followed by final class NetworkTimeout extends AuthFailure { const NetworkTimeout(); } and so on. For variants that carry contextual data (e.g., oauthError carrying the raw code string), use a named parameter in the constructor.

For the Result type, either use a package like fpdart (Either) or define a minimal sealed Result in the same domain folder — do not pull in a new dependency if the project doesn't already use one; check existing dependencies first. Ensure the error type file has no imports from Flutter (dart:ui, package:flutter) — it must be a pure Dart file so it can be used in Edge Function Dart code if needed. Document the mapping from Vipps OAuth error response fields (error, error_description) to AuthFailure variants in a code comment for future maintainers.

Write Dart unit tests covering: (1) each sealed class variant can be instantiated with expected properties, (2) pattern matching (switch/when) over AuthFailure is exhaustive — verified by adding a new variant and confirming the compiler error, (3) message and detail fields do not contain NIN or phone number values in any variant's default factory, (4) const constructors are used for fixed variants (verify with identical() check). No widget tests needed for this task — pure model layer. Run dart analyze with zero warnings on the new files.