fix(perps): preserve stream cache across Android background teardown

[abretonc7s]

Description

Preserves same-session Perps stream caches when Android's background grace-period timer disconnects the transport. Active in-app teardown and account/provider/network changes keep their existing hard-clear behavior.

Stacked on #34474. Review only the two-file diff against fix/perps-stream-recovery.

Why

On a physical Pixel 6, a 25-second background interval expired the Android grace timer and cleared the last visible positions/orders. Foreground recovery therefore had no resident order to paint even though the account/provider session had not changed.

With this change, the identical recipe restored the resident ETH order in 958.624 ms. That run separately exposed the Homepage orders throttle; it is intentionally not fixed here and will be the next stacked PR.

Test scenarios

Scenario: Resume after Android background grace-period expiry
  Given Perps has a visible order in the current account and provider session
  When the app remains backgrounded beyond the disconnect grace period
  Then the transport disconnects
  And the same-session positions and orders caches remain available for foreground paint

Scenario: Expire an active in-app disconnect grace period
  Given the app is active and no Perps consumer retains the connection
  When the disconnect grace period expires
  Then the transport disconnects
  And all stream caches are cleared as before

Validation

• PerpsConnectionManager.test.ts: 78/78 pass on this exact branch.
• Physical Android before: android-homepage-background-reconnect-v1 lost resident cache after 25 seconds backgrounded.
• Physical Android after: android-homepage-background-reconnect-v2 rendered the resident order at 958.624 ms.
• Full-run videos, traces, logs, summaries, manifests, and screenshots are retained locally; no public artifact upload was performed.

Risk

The preservation condition is limited to an Android timer armed while the app is not active. Identity changes and explicit/active teardown continue to clear caches.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokePerps, SmokeWalletPlatform, SmokeConfirmations
• Selected Performance tags: @PerformancePreps
• Risk Level: medium
• AI Confidence: 88%

click to see 🤖 AI reasoning details

E2E Test Selection:
The changes are confined to PerpsConnectionManager.ts and its test file. The functional change introduces a preserveCaches flag for Android's grace period disconnection: when the app is in background state (AppState !== 'active'), caches are preserved during transport disconnection so foreground recovery can paint cached data first. When the app is active (in-app teardown), caches are still cleared as before.

This affects:

1. SmokePerps: Directly impacts Perps connection management, balance display after background/foreground transitions, and the Add Funds flow on Android. The cache continuity change could affect how balances are shown after the app returns from background.
2. SmokeWalletPlatform: Required per SmokePerps tag description (Perps is a section inside Trending tab).
3. SmokeConfirmations: Required per SmokePerps tag description (Add Funds deposits are on-chain transactions).

The change is Android-specific and well-tested with new unit tests. Risk is medium because it changes connection/cache behavior that could affect data freshness in the Perps UI.

Performance Test Selection:
The PerpsConnectionManager change introduces cache preservation during background-to-foreground transitions on Android. This is a performance-relevant optimization: instead of clearing caches and fetching fresh data on foreground recovery, the app now paints from cache first. This directly affects the Perps market loading and balance display performance measured by @PerformancePreps. The change could improve perceived performance (cache-first rendering) but should be validated to ensure it doesn't introduce stale data display issues that could affect measured performance metrics.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud