feat: hide bootstrap status messages behind triple-tap easter egg

Status messages and commit hash during wallet initialization are now hidden
by default. Tap the loading logo three times (within 600ms between taps) to
toggle them on/off. This keeps the boot animation clean for normal users while
preserving debug visibility for developers and testers.

Implementation:
- Add statusRevealed state (default false) to gate text and commit hash render
- Add tap counter with 600ms timeout to track triple-tap gesture
- Make logo tappable by adding pointerEvents: auto wrapper
- Change text and commit hash conditions to require statusRevealed

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

Author: pietro909

BOOT_ERROR.agents.md

@@ -0,0 +1,61 @@
+# Plan: Retry prompt when first wallet data load fails
+
+## Context
+
+After commit 0b4da778 fixed the loading-screen deadlock by setting `dataReady = true` in a `finally` block, a failed first `reloadWallet` silently falls through to an empty wallet with no error or retry path. We want to keep the user on the boot loading screen with a retry prompt instead.
+
+## Approach
+
+Replace the "always set dataReady on failure" strategy with an explicit error state that holds the loading gate open and shows a retry UI.
+
+### 1. Add `loadError` state to WalletContext (`src/providers/wallet.tsx`)
+
+- New state: `const [loadError, setLoadError] = useState<string | null>(null)`
+- Add to `WalletContextProps` interface, default context value, and provider value
+- Expose `dismissLoadError` function that sets `dataReady = true` (continue to empty wallet)
+
+### 2. Modify `reloadWallet` catch/finally (`src/providers/wallet.tsx:~308-318`)
+
+- **catch block**: On first load (`!hasLoadedOnce.current`), set `loadError` with a user-facing message, call `clearLoadingStatus()`, but do NOT set `dataReady = true` or `hasLoadedOnce = true`. This keeps `shouldHoldOnLoading` true so the user stays on the loading screen.
+- **finally block**: Remove entirely — the catch now handles the first-load failure, and the try block already handles success.
+- On retry: `reloadWallet` clears `loadError` at entry before trying again.
+
+### 3. New component: `BootError` (`src/components/BootError.tsx`)
+
+A full-screen overlay (matching LoadingLogo's visual layer) that shows:
+- Centered layout using inline styles matching CenterScreen's pattern (flex column, centered, max-width 18rem)
+- Themed background (`var(--ion-background-color)`) covering the full viewport like LoadingLogo's portal
+- Error text: `Text` component with the error message
+- "Retry" button: primary `Button` with `loading` state while retrying
+- "Continue anyway" button: secondary/clear `Button` that calls `dismissLoadError`
+
+Rendered via `createPortal` to `document.body` (same as LoadingLogo) so it sits at the same z-layer.
+
+### 4. Wire up in App.tsx (`src/App.tsx:~385-392`)
+
+Replace the boot animation block:
+```tsx
+{bootAnimActive ? (
+  loadError ? (
+    <BootError />
+  ) : (
+    <LoadingLogo ... />
+  )
+) : null}
+```
+
+Pull `loadError`, `reloadWallet`, `dismissLoadError` from `WalletContext`.
+
+## Files to modify
+
+| File | Change |
+|---|---|
+| `src/providers/wallet.tsx` | Add `loadError` state, modify `reloadWallet` catch/finally, add `dismissLoadError`, update interface + provider value |
+| `src/components/BootError.tsx` | **New file** — retry prompt component |
+| `src/App.tsx` | Destructure new context fields, conditionally render `BootError` vs `LoadingLogo` |
+
+## Verification
+
+1. `pnpm build` — no type errors
+2. `pnpm lint && pnpm format:check` — clean
+3. Manual test: temporarily inject `throw new Error('test')` at the top of `reloadWallet`'s try block, verify the retry prompt appears on boot, retry works, "continue anyway" proceeds to empty wallet

E2E_FAILING.md

@@ -0,0 +1,80 @@
+# E2E Test Failures on `feat/loading-status-messages`
+
+## Root Cause
+
+The branch changed `shouldHoldOnLoading` in `App.tsx:223` from:
+
+```js
+// master:
+const shouldHoldOnLoading = hasStoredWallet && !initialized && authState !== 'locked'
+// branch:
+const shouldHoldOnLoading = hasStoredWallet && (!initialized || !dataReady) && authState !== 'locked'
+```
+
+This keeps the loading screen visible (and `comp = null` — no page content rendered) until `reloadWallet()` completes and sets `dataReady = true`. On master, the wallet page renders immediately after `initialized` becomes true.
+
+Two consequences for tests:
+
+1. **Wallet readiness takes longer** — `createWallet()` and `restoreWallet()` waited for `text=Send` with a 30s timeout. On this branch, `Send` only appears after `reloadWallet` finishes (extra seconds). If `reloadWallet` fails, a `BootError` overlay ("Continue anyway" / "Retry") blocks the UI instead.
+
+2. **`reloadWallet` failure on first load blocks the app** — On master, failures were silently ignored. On this branch, `loadError` is set and `BootError` renders as a full-screen overlay. Tests don't handle this.
+
+## Fixes Applied
+
+### 1. `waitForWalletPage` helper (`src/test/e2e/utils.ts`)
+
+Handles both the normal path (`Send` visible) and the error path (`Continue anyway` visible):
+
+```ts
+export async function waitForWalletPage(page: Page, timeout = 60000): Promise<void> {
+  const sendBtn = page.getByText('Send', { exact: true })
+  const continueBtn = page.getByText('Continue anyway')
+  await sendBtn.or(continueBtn).first().waitFor({ state: 'visible', timeout })
+  if (await continueBtn.isVisible()) {
+    await continueBtn.click()
+    await sendBtn.waitFor({ state: 'visible', timeout: 30000 })
+  }
+}
+```
+
+Used in `createWallet()`, `restoreWallet()`, and `delegate.test.ts` (post-reload wait).
+
+### 2. `waitForPaymentReceived` timeout (`src/test/e2e/utils.ts`)
+
+Increased from default 30s to 60s. The Boltz reverse-swap claim path can exceed 30s on slow CI runners.
+
+## Remaining Issue: `restore.test.ts` Lightning payment not detected
+
+### Symptom
+
+`waitForPaymentReceived` times out even at 60s. The page snapshot shows the QrCode/Receive page is correctly displaying the Lightning invoice, but "Payment received!" never appears.
+
+### Key finding: `exec` vs `execSync`
+
+The test uses fire-and-forget `exec()` to pay the Lightning invoice via lnd:
+```js
+exec(`docker exec lnd lncli --network=regtest payinvoice ${invoice} --force`)
+```
+
+- **`execSync`** (blocking): payment works instantly, test passes
+- **`exec`** (fire-and-forget): payment never completes, test times out
+
+On master, fire-and-forget `exec` works fine. On this branch, it does not.
+
+### Cascading failure
+
+Each failed attempt leaves an IN_FLIGHT HTLC in lnd that never settles. After several failed runs, lnd accumulates stuck HTLCs that block all new payments on the channel. This makes subsequent runs fail even more reliably.
+
+### Theories investigated but not confirmed
+
+- **Navigation effect re-firing**: The `wallet.tsx:256-278` effect navigates to `Pages.Wallet` when `initialized && dataReady`. If `initialized` flickers (status ping returning false temporarily), the effect could re-fire and bounce the user off the QrCode page, unmounting the payment listener. However, the same effect exists on master.
+
+- **QrCode component unmount**: If `shouldHoldOnLoading` becomes true mid-test (e.g., `initialized` flickers), `comp = null` destroys all page content including the QrCode component and its `listenForPayments` handler. The swap's `waitAndClaim` promise and the VTXO_UPDATE listener are lost. This is unique to the branch since master's `shouldHoldOnLoading` is less likely to re-trigger.
+
+- **`exec` child process blocking on stdout pipe**: Unlikely given the small output size of `payinvoice`.
+
+### Suggested next step
+
+Change the `exec` call at `restore.test.ts:44` (and similar in `swap.test.ts:40`, `nostr.test.ts:84`) to use `execAsync` so the payment is confirmed before waiting for wallet detection. The test already imports `execAsync = promisify(exec)`.
+
+Alternatively, investigate why `exec` (fire-and-forget) works on master but not on this branch — likely related to the `initialized` state flickering causing component unmounts via `shouldHoldOnLoading`.