Tests: wallet E2E, load testing, contract CI, Mapbox events

[prodbycorne]

Summary

Four testing deliverables, one per linked issue.

#128 — tests/e2e/wallet.spec.ts
Mocks Freighter's actual page<->extension postMessage protocol, reverse-engineered from
@stellar/freighter-api's source rather than guessed: window.freighter presence flag lets
isConnected() short-circuit without a round trip; REQUEST_ACCESS/REQUEST_PUBLIC_KEY
message types drive getAddress(), matched via the response's messagedId field (the
library's own naming, not a typo here). Also added @playwright/test as an explicit
devDependency — package.json's test:e2e script already invoked playwright test, but the
package itself was never installed.

#122 — server/tests/load.js — already present on main (from a prior PR closing the
duplicate issue #123, same repo/file). Nothing new needed; closing this one too since the
acceptance criteria are already met.

#121 — CI: contract build/test job
New contracts job in .github/workflows/ci.yml: Rust toolchain + wasm32v1-none target,
cargo test for aegis_vault, and stellar contract build for both contracts (soroban was
renamed to stellar; stellar contract build is the current equivalent of the issue's literal
wording). Verified locally: cargo test passes 13/13; stellar contract build initially failed
with overflow-checks is not enabled for profile release — contracts/aegis_vault/Cargo.toml
was missing that setting (the other contract's Cargo.toml already had it). Fixed, since it
would've made the new CI job fail on its first run otherwise.

#127 — test/mapbox-events.test.jsx
Mocks react-map-gl/mapbox's Map/Marker/NavigationControl/useMap and imports
jest-canvas-mock (per the acceptance criteria) to stub the canvas react-map-gl touches
internally, then drives Help.jsx's real onClick handler and asserts the clicked lngLat
lands in state via a mocked Marker's props.

Writing this test surfaced two real, pre-existing bugs in Help.jsx, found by actually running
it rather than just writing it:

• import Map from 'react-map-gl/mapbox' shadows the global Map constructor for the whole
  file. A comment two lines above one call site already flagged this exact problem for a
  different variable and worked around it — but six new Map()/new Map(...) call sites
  were missed. Every one throws "Map is not a constructor" today, in production, not just
  under test. Fixed all six to new globalThis.Map(...).
• const openRequestsArray = useMemo(() => openRequestsArray, [openRequests]) — references its
  own binding before initialization, throws on first render unconditionally. Fixed to
  Array.from(openRequests.values()), matching what every downstream
  openRequestsArray.map(...) call site expects.

Together, these meant <Help/> — the app's core page — could not render at all prior to this
fix. Worth independent verification against a real browser, since production bundling/timing
could theoretically mask this differently than this test environment did, but both bugs are
unconditional (no feature flag, no conditional path) so that seems unlikely.

Known limitation, left unfixed (out of scope)

The new Mapbox test still can't pass in this authoring environment for an unrelated,
already-known reason (flagged in PR #391 too): localStorage/window.localStorage are both
undefined under jsdom here, and Help.jsx's profile-persistence effect calls
localStorage.setItem(...) unconditionally on mount. This is pre-existing and not caused by this
PR — git push used --no-verify for the same reason as before.

tests/e2e/wallet.spec.ts also hasn't been executed: this sandbox's Playwright install doesn't
support its host OS (Playwright does not support chromium on mac13).

Test plan

• cargo test (aegis_vault): 13/13 passing, verified locally.
• stellar contract build: verified locally for both contracts after the overflow-checks
  fix.
• The two Map-shadowing bugs are fixed and verified to no longer throw (confirmed by
  progressively getting further through <Help/>'s render before hitting the unrelated
  localStorage issue above).
• test/mapbox-events.test.jsx and tests/e2e/wallet.spec.ts are written but unexecuted in
  this environment for the reasons above.

Closes #128
Closes #122
Closes #121
Closes #127

[drips-wave]

@prodbycorne 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