feat(mobile): update background images for wallet 4.0

[LucasWerey]

✅ Checklist

• npx changeset was attached.
• Covered by automatic tests. UI-only image asset changes, no logic to unit test.
• Impact of the changes:
  - Wallet tab background rendering in both light and dark themes
  - Card landing screen background image display
  - Earn screen background image display
  - Verify v4-light.webp and card-bg.webp render correctly across devices

📝 Description

Wallet 4.0 light mode was previously using a solid gradient background while dark mode had a dedicated image. This PR adds a v4-light.webp background image for wallet 4.0 light mode and updates all screens to use theme-aware image backgrounds consistently.

Changes:

• WalletTabBackgroundGradient: Now uses v4-light.webp for wallet 4.0 light mode instead of falling back to a solid color gradient. Removed the gradient overlay logic (previously only for dark mode) in favor of letting the images handle the visual treatment directly.
• CardLandingScreenView: Refactored to receive backgroundImageSource as a prop, removing the hardcoded dark-only image. Now displays a background image in both light and dark modes.
• useCardLandingScreenViewModel: Selects between card-bg.webp (dark) and v4-light.webp (light) based on the current theme.
• EarnBackground: Updated to use earn-bg-dark.webp / v4-light.webp based on theme instead of showing a background only in dark mode.
• Assets: Added v4-light.webp, replaced card-landing-bg.webp with card-bg.webp, updated v4-dark.webp.

Full demo (ff ON/OFF):

Simulator.Screen.Recording.-.iPhone.17.Pro.Max.-.2026-03-02.at.18.46.21.mov

❓ Context

• JIRA or GitHub link: LIVE-27112

---

🧐 Checklist for the PR Reviewers

• The code aligns with the requirements described in the linked JIRA or GitHub issue.
• The PR description clearly documents the changes made and explains any technical trade-offs or design decisions.
• There are no undocumented trade-offs, technical debt, or maintainability issues.
• The PR has been tested thoroughly, and any potential edge cases have been considered and handled.
• Any new dependencies have been justified and documented.
• Performance considerations have been taken into account. (changes have been profiled or benchmarked if necessary)

[sonarqubecloud]

Quality Gate failed

Failed conditions
26.3% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud