feat(deps): adopt flutter_riverpod 3

[mpge]

Supersedes #12, which failed CI.

Dependabot's PR bumped the constraint and changed nothing else, so flutter analyze failed with 169 errors across 24 files: StateNotifier resolved to nothing, which made every state reference undefined and cascaded into every screen and widget that reads a provider.

Riverpod 3 did not delete these APIs

It moved StateNotifier, StateNotifierProvider, StateProvider and ChangeNotifierProvider out of the default export and into package:flutter_riverpod/legacy.dart, where they remain supported. The four provider files now import from there, and the 169 errors go to zero.

theme_provider.dart uses nothing from the main export once the legacy import is added, so it imports only legacy.dart — otherwise the analyzer reports an unused import. That was the one extra issue on my first pass (84 vs the 83 baseline), now resolved.

What I deliberately did not do

I did not migrate the seven notifiers to Notifier/NotifierProvider in this PR, even though that is the intended destination and StateNotifier is legacy.

That is a behavioural rewrite rather than a rename. A Notifier returns its initial state from build() instead of a constructor, so constructor side effects have to be re-homed — AuthNotifier calls checkAuth() from its constructor today, and state cannot be assigned during build(). Getting that subtly wrong changes when state is produced, which is exactly the kind of thing that does not show up in analysis.

This package ships two tests. That is not a net you can do a seven-notifier state-management rewrite over. The README now records the migration as the next step, gated on widget coverage first.

If you would rather take the rewrite now and accept the risk, say so and I will do it — I just do not think it should ride along unreviewed inside a dependency bump.

Verification

flutter analyze 0 errors, 0 warnings, 83 infos — exactly the pre-change baseline, and flutter test 2/2, resolved against flutter_riverpod 3.4.3 (confirmed via flutter pub deps).

example/ tracks the same constraint so the workspace resolves as one; without that, pub fails outright.

Note this one pins ^3.4.3 rather than widening, for the same reason file_picker did in #10: v2 and v3 need different import lines, so a range spanning both would be a promise the code cannot keep.

[mpge]

Pushed a second commit — the first one was not enough, and the reason is worth recording.

flutter_riverpod >=3.4.1 requires Dart ^3.12.0. CI pins Flutter 3.38.10, which ships Dart 3.10.9, so pub could not even resolve:

Because escalated depends on flutter_riverpod >=3.4.1 which requires
SDK version >=3.12.0 <4.0.0, version solving failed.

So this PR now also raises environment to sdk >=3.12.0 / flutter >=3.44.0 and moves the CI pin to 3.44.x.

The trade-off to weigh

This narrows the supported Flutter window from >=3.19.0 to >=3.44.0 — the real cost here, on a published package.

Riverpod 3 raises the floor whichever 3.x you pick, so the question is how far, not whether:

flutter_riverpod	Requires Dart
3.0.0	^3.8.0
3.2.0	^3.7.0
3.4.1+	^3.12.0

Pinning ^3.0.0 instead would need only Dart ^3.8.0 — CI's current Dart 3.10.9 would resolve it with no Flutter bump and a much smaller support-window change. The downside is that Dependabot will then re-propose 3.4.x indefinitely.

I took the current release on the assumption that keeping the dependency current beats preserving Flutter 3.19–3.43 support for a package whose CI pin was already two years of releases behind. If that support window matters to you, say so and I will switch this to ^3.0.0 — it is a one-line change.

Analyzer infos go 83 → 91; all eight new ones are use_null_aware_elements, a lint that ships with Dart 3.12, and none are errors or warnings.