fix(ci): pin Flutter version in .fvmrc

[leoafarias]

Summary

Pins .fvmrc to 3.41.9 (current Flutter stable) so the CI workflows resolve a non-empty FLUTTER_VERSION.

Why

All four workflows (firebase-hosting-pull-request.yml, plus test, integration-test, web-smoke in test.yml) use:

- uses: kuhnroyal/flutter-fvm-config-action@v2
  id: fvm-config-action
- uses: subosito/flutter-action@v2
  with:
    flutter-version: \${{ steps.fvm-config-action.outputs.FLUTTER_VERSION }}
    channel: stable

After 5fc2298 set .fvmrc to { "flutter": "stable" }, the action returns an empty FLUTTER_VERSION. Subosito installs latest stable (3.41.9 today), and melos bootstrap then fails on packages/superdeck (the only Flutter SDK package) with:

Failed to download https://storage.googleapis.com/flutter_infra_release/flutter//engine_stamp.json
Exception: 404

The double slash is an empty version segment — a Flutter 3.41.9 regression when resolving engine info from a prebuilt SDK with an unresolved version. Other (pure Dart) packages bootstrap fine.

The breakage is invisible on PRs from forks because the firebase-hosting workflow gates on pull_request.head.repo.full_name == github.repository.

Test plan

• CI on this PR runs melos bootstrap cleanly across all four workflows
• superdeck package resolves dependencies without the engine_stamp 404

[docs-page]

To view this pull requests documentation preview, visit the following URL:

docs.page/btwld/superdeck~71

Documentation is deployed and generated using docs.page.

[leoafarias]

Superseded — the test workflows pass with empty FLUTTER_VERSION, so pinning isn't the fix. The actual root cause is fvm use --force in the firebase-hosting workflows (not present in test.yml). Replacing with a workflow-only fix.