Align CI Flutter version with current stable to resolve the analyzer 7→8 toolchain split

[Catrya]

Problem

The repository's committed pubspec.lock and CI are pinned to a Flutter version that sits on the analyzer 7.x side of a breaking toolchain boundary, while current Flutter stable is on analyzer 8.x. A single committed lockfile cannot serve both sides cleanly, which produces a developer-experience break for any contributor on current Flutter.

Concretely:

• CI runs on Flutter 3.32.2 (.github/workflows, FLUTTER_VERSION: '3.32.2') → Dart 3.8 → only analyzer 7.x is installable (analyzer 8.x requires sdk: ^3.9.0).

• The committed pubspec.lock pins analyzer 7.7.1 + source_gen 3.1.0 — a self-consistent, working combination on CI. This is why CI and releases are green.

• Contributors on Flutter 3.41+/3.44 (Dart 3.11+) get analyzer 8.x on a clean flutter pub get, but the lock keeps source_gen 3.1.0 (which declares support for analyzer <9.0.0 even though its code calls
  DartObjectImpl.getInvocation(), a method removed in analyzer 8.x). Result: dart run build_runner build -d fails with:

  source_gen-3.1.0/lib/src/constants/revive.dart:82:40: Error: The method
  'getInvocation' isn't defined for the type 'DartObjectImpl'.

This is the root cause behind #606. It is not a project code bug and does not affect the app, the build output, or CI (generated *.g.dart/*.mocks.dart are not committed and CI regenerates them on 3.32.2). It is a toolchain-version split that blocks local code generation for anyone on current Flutter stable.

Why this is its own issue

The same analyzer 7→8 wall surfaces through more than one dependency chain:

• Dart run build_runner build fails on Flutter 3.44.0, source_gen 3.1.0 incompatible with analyzer 8.x #606 — source_gen (pulled via mockito → build_runner). This is the chain that actually breaks in this repo.
• Migrate from Riverpod 2.x to Riverpod 3.x #512 — the Riverpod ecosystem pins analyzer ^7.0.0. Note: this repo currently uses no Riverpod code generation (no @riverpod / riverpod_annotation; riverpod_generator/custom_lint/riverpod_lint are not in the dependency tree), so the Riverpod pin is not an active blocker here, but it is part of the same modernization frontier.

Resolving #606 does not resolve #512 and vice versa. Bumping CI Flutter to current stable is the umbrella that requires both chains to land on the analyzer-8 side.

Proposed resolution

1. Bump the CI Flutter version (.github/workflows) from 3.32.2 to current stable (e.g. 3.44.x), so the whole toolchain lives on a single side of the analyzer 7→8 boundary.
2. Regenerate and commit pubspec.lock on the new toolchain so it resolves cleanly on analyzer 8 (this upgrades source_gen 3.1.0 → 4.2.3, which supports analyzer >=8.1.1 and no longer uses getInvocation(); the rest of the codegen toolchain — build, build_runner, mockito — is unaffected).
3. Verify Riverpod runtime (flutter_riverpod/hooks_riverpod 2.6.1) builds on the new Flutter. Since no Riverpod codegen is used, a full Riverpod 3.x migration (Migrate from Riverpod 2.x to Riverpod 3.x #512) may not be required just to bump Flutter — confirm before deciding.
4. Validate the new toolchain end to end: flutter analyze, flutter test, and flutter test integration_test/ must pass on the new version; address any new deprecations introduced by the Flutter bump.

Notes / scope

• This supersedes the local workarounds (flutter pub upgrade source_gen, or flutter gen-l10n for ARBs) that contributors currently rely on.
• No changes to pubspec.yaml constraints are required for the source_gen part; regenerating the lock on the newer SDK is sufficient.
• Related: Dart run build_runner build fails on Flutter 3.44.0, source_gen 3.1.0 incompatible with analyzer 8.x #606 (the source_gen symptom), Migrate from Riverpod 2.x to Riverpod 3.x #512 (Riverpod modernization).