feat: add expo-example app

[andrascodes]

This PR is part of a stack created with Aviator. feat(expo-example): add export wallet on mobile #168 feat(expo-example): configure and add magic link login #142 fix(expo-example): add EAS local build config and fix HMR bug with secureStoreStamper #141 feat(expo-example): migrate to expo-router #131 feat(react): enable OAuth in React Native #80 feat(expo-example): add Passkey auth and test on Android #124 ➡️ feat: add expo-example app #76 main

Closes FS-1929

Added an expo-example app to test wallet-react. I needed to do a couple stuff to make Expo/Metro work with the monorepo and the packages:

1. Adding babel.config.js to get rid of the import.meta error

Added nodeLinker: hoisted to the workspace file and the NPM config file.
- This is needed to make the example app work, however, it can cause drawbacks with module resolution. (Source) We can discuss the best strategy here. On one hand, the example apps make it a lot easier to test the packages while developing. It's not a good option to install local modules in Expo as it's cumbersome and requires frequent bundle cache and node_modules resets. On the other hand, I do understand the drawbacks can be more annoying.

Hoisted deps alone did not work to resolve multiple package versions so I had to add overrides here.

Got inspired from Omar's PR and I added a Metro config instead to link to the correct modules. This might make some new package installs brittle so we need to keep extending it but it beats having to make global dep management modifications to the repo for the sake of an example app.
Claude's explanation:

⏺ The metro config solves a problem caused by pnpm in monorepos: duplicate package copies.

When packages/react and apps/expo-example both depend on wagmi, pnpm installs two separate copies in its .pnpm store (even with node-linker=hoisted) because their transitive dependency trees differ slightly. Metro then bundles both copies, meaning WagmiProvider from one copy creates a React context that useConfig from the other copy can't find.

What the config does:

config.resolver.resolveRequest = (context, moduleName, platform) => {

It intercepts Metro's module resolution. For every import in the bundle, this function decides where the module comes from.

Two categories of overrides:

1. workspaceSingletons (react, wagmi, @wagmi/core, @tanstack/react-query, react-dom) — Only redirected when the import originates from packages/* (your workspace libraries). This is scoped because redirecting these globally would break wagmi's own internal imports of @wagmi/core etc.
2. globalSingletons (tslib) — Redirected for ALL imports regardless of origin. Safe because tslib is a standalone utility with no internal dependencies.

How the redirect works:

return context.resolveRequest(
{ ...context, originModulePath: appPackageJson },
moduleName,
platform,
)

It lies to Metro about where the import is coming from — instead of resolving from packages/react/dist/..., it resolves as if the import came from apps/expo-example/package.json. Metro then walks up from there, finds apps/expo-example/node_modules/wagmi, and uses the app's copy. This ensures a single copy of each package ends up in the bundle.

[SahilVasava]

Looks solid. Three inline nits — naming, getPublicKey returning null, and lost yaml comments. Nothing blocking.