draft: refresh low-risk app dependencies

[AlexTzib]

Hi @Manuito83, opening a second draft dependency-update PR so CI can test a small low-risk app batch separately from the generator/tooling update.

This batch updates small patch/minor dependencies that should be mostly compile/test validated by CI:

• cookie_jar
• crypto
• cupertino_icons
• flutter_slidable
• flutter_svg
• provider
• shared_preferences
• synchronized
• url_launcher
• vibration

Local checks:

• flutter test passed in Docker
• git diff --check passed
• local flutter analyze was started in Docker, but like the first dependency batch it stayed silent for several minutes, so I stopped the local container and am leaving GitHub CI as the clean analyzer/build gate.

I intentionally avoided Firebase, WebView, auth/sign-in, file picker, connectivity, notifications, and other broader platform/runtime updates in this batch.

[AlexTzib]

Hi @Manuito83, same policy question here before this draft should be considered ready.

This PR moves these low-risk dependency constraints from exact pins to caret ranges. Because pubspec.lock is ignored in this repo, future CI/local runs can resolve newer package versions than the ones that passed today.

Do you prefer dependency update PRs to keep exact versions in pubspec.yaml so the tested version is the version we continue resolving, or is moving selected packages to caret ranges acceptable?

I can adjust this PR either way.

[Manuito83]

I've had many issues in the past where some dependencies introduced breaking changes in minor versions, which is why I'm enforcing every single version. On the other hand, looking at the every changelog takes time, but it also gives us additional info on new features.

The Flutter ecosystem has evolved quite a lot in the last few years, so I guess it should now be safe(r) to allow dependencies to update.

[AlexTzib]

Thanks, that makes sense.

I adjusted this draft to keep the updated app/runtime dependencies pinned to exact versions instead of changing these entries to caret ranges. My thinking is that this keeps the versions GitHub CI tests as the same versions future installs resolve, which feels safer while pubspec.lock is not committed.

A possible middle ground from here:

• keep runtime dependency refresh PRs pinned and small, like this one
• use CI as the gate for each batch
• discuss caret ranges separately later, maybe starting with very low-risk pure Dart/dev tooling packages rather than app/runtime packages

So this PR is now only a dependency refresh, not a dependency-policy change.

[Manuito83]

I'll merge this, thanks!