test(e2e): reconnect after session expiry with data-loss verification

[onuibeblessing2019-hash]

Closes #321

Important scope disclosure — read before reviewing

This repo has no client-side session-expiry detection today:

• WalletSession (@vellar/types) carries no expiresAt field.
• apps/web/lib/wallet-context.tsx never checks for a 401 and never auto-triggers a reconnect prompt.
• The server-side 7-day sliding-window expiry (services/wallet-service/src/server.ts's SESSION_TTL_MS/resolveSessionCapability) is exercised only by that service's own existing unit test (server.test.ts: "an EXPIRED session bearer is treated as ABSENT") — it is never surfaced to the UI.
• idea.md (referenced by wallet.spec.ts's own existing comment, "§15") does not exist anywhere in this repository as of writing — could not verify the scenario's exact original wording.
• The extension has no analogous session-expiry concept at all to reconnect from — its persisted state (apps/extension/lib/state.ts's PairedWallet) is a pairing (address/network/RPC/origin) that never expires on its own; the closest thing, the device signer's own 7-day expiry (signer-expiration.ts), is an on-chain signing-authority bound enforced by the contract, not a UI flow. There is nothing there to write a meaningful "extension reconnect" test against, so I did not fabricate one — flagging this explicitly rather than silently skipping the extension half of the issue's ask.

Given that, there is currently no UI behavior that distinguishes "your session expired" from a manual disconnect — both look identical to a user (no persisted session; "Sign in" is the only way back). This PR's new test therefore uses the same trigger the existing "create, fund, pay, reconnect" scenario already uses (manual disconnect, the only reconnect trigger the app actually implements) as the stand-in for expiry, and focuses its actual new value on the part of #321's acceptance criteria the existing test does NOT check: verifying no data loss across reconnect.

What's here

• apps/web/e2e/wallet.spec.ts:
  • Extracted the repeated CDP virtual-authenticator setup into a shared enableVirtualAuthenticator helper (used by both the pre-existing test and the new one — was duplicated inline before).
  • New test: "reconnect after a lost session regains access with no data loss (live testnet)". Creates and funds a wallet, records the current server-side session via the Settings page's "This device" entry, disconnects, reconnects with the same passkey, then verifies: (a) same contract id, (b) balance unchanged (10 XLM, not reset), (c) a genuinely new server-side session is now current (the Settings "This device" entry's text changed) — proving access was actually re-established via a fresh session, not a stale rehydrated one.

Why this couldn't be executed here

Per playwright.config.ts's own comment, this suite requires api-gateway (:4000) and wallet-service (:4001) running with real relayer + Postgres config, against live Stellar testnet with real friendbot funding. None of that infrastructure is available in this environment. Verified as much as is possible without it:

• npx playwright test --list — both tests parse and are discovered correctly (2 tests in 1 file), confirming no syntax/structural errors.
• npx tsc --noEmit in apps/web — 20 errors, byte-identical before and after this change (confirmed via a stash/restore diff) — zero new errors introduced. All 20 are pre-existing and unrelated (a WalletSession.contractId/sessionId mismatch in dashboard/page.tsx, strict-null issues in analytics.test.ts, and the workerProcessingLagSeconds is not defined bug in packages/service-kit already flagged and fixed independently in feat: RPC timeout budgets for policy deploy + circuit breaker for verification-service #381/fix(lifecycle-service): invalidate cached account reads after merge #384).

I was not able to run this against real testnet infrastructure — flagging clearly so a reviewer with that environment available can do a real run before relying on this test in CI.

Closes #321

[drips-wave]

@onuibeblessing2019-hash Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[vercel]

@onuibeblessing2019-hash is attempting to deploy a commit to the david's projects Team on Vercel.

A member of the Team first needs to authorize it.

[onuibeblessing2019-hash]

closes #321