fix: upgrade mobile_scanner to 7.4.0 for arm64 iOS-26 simulator support

[TaprootFreak]

Problem

mobile_scanner 5.2.3 depends on GoogleMLKit, whose frameworks ship no arm64-iphonesimulator slice. On GitHub's arm64 macOS runners the iOS 26 simulator is arm-only (Apple removed Rosetta for the iOS 26 simulator), so the app could neither build nor run there — breaking the tier3-handbook CI with Framework 'Pods_Runner' not found. This is what red-flags the staging→develop promote.

Note: mobile_scanner was reintroduced in #674 at ^5.2.3 in pubspec but without a matching pod install / ios/Podfile.lock commit, leaving the lockfile out of sync. This PR both bumps the version (5.2.3 → 7.4.0) and restores lockfile consistency.

Fix

Upgrade mobile_scanner to 7.4.0, which drops GoogleMLKit for Apple's native Vision API → the app builds and installs/launches natively on arm64 iOS 26.5 simulators.

• Migrate the two errorBuilder call sites to 7.x's 2-arg signature (dropped the unused Widget? child).
• QrScannerView now supplies a compact, textScale-safe default error placeholder (icon-only) so 7.x's taller default no longer overflows send_recipient_page's bounded Expanded at large accessibility text sizes.
• Add a no-op stub for mobile_scanner 7.x's new deviceOrientation event channel in the golden-test helper, plus a focused widget test asserting the default placeholder stays overflow-safe at TextScaler.linear(3.0).

Verification

• flutter build ios --simulator --debug → succeeds; simctl install + launch on iPhone 17 / iOS 26.5 → succeeds (no arch error, app renders).
• flutter analyze clean; flutter test --exclude-tags golden → all pass.
• Golden baselines regenerated on the self-hosted runner (one changed: the send scanner error icon).
• Tier 3 handbook flows (iOS build + 26 Maestro flows) and RealUnit Build (analyze/test, visual regression, coverage, BitBox) both green on the branch head.

Note on the scanner backend

The iOS scan backend changes GoogleMLKit → Apple Vision. The app only consumes Barcode.rawValue, so Dart-side handling is unchanged. QR-decode parity between the two backends is architecturally expected (both fully support the QR symbology) but has not been verified against a live camera — the scanner is @no-integration-test and cannot run in CI, so a device smoke-test (bare address, checksummed address, ethereum: URI, LNURL) is worth doing before release.

[TaprootFreak]

Ready for review — this went through 2 review passes to zero code findings.

• Pass 1 surfaced a missing focused regression test for the scanner's default error placeholder and an incomplete root-cause note → added test/widgets/scanner/qr_scanner_view_test.dart (asserts the placeholder stays overflow-safe at TextScaler.linear(3.0)) and clarified the description (the dependency was reintroduced in feat: OCP pay-flow (RealU→ZCHF→Open CryptoPay) #674 without a Podfile.lock sync).
• Pass 2 flagged that the original "no format regression" wording overstated what was actually verified locally → the description now states plainly that GoogleMLKit → Apple Vision QR-decode parity is architecturally expected but not verified against a live camera (a device smoke-test before release is recommended, since the scanner is @no-integration-test).

Validated on the branch head: Tier 3 handbook flows (iOS build + 26 Maestro flows) and RealUnit Build (analyze/test, visual regression, coverage floor, BitBox) both green — this is the check that was failing the staging→develop promote.