Fetch recovery status when walletId is missing instead of fake delay

[chidinma000]

Problem

useRecovery(null) (no wallet selected) ran a simulated setTimeout(1200)
"bootstrap" before flipping to idle — a demo stub masquerading as a status
fetch. The loading skeleton on /recovery was driven by a fake timer rather
than any real request.
closes #620

Change

• Removed the simulated bootstrap entirely from useRecovery — the
  stubLoaded/stubError state, the setTimeout(1200) effect, and the
  now-unused useEffect import are gone.
• Added UseRecoveryOptions { walletsLoading?: boolean }. When walletId
  is null there is no wallet to fetch a per-wallet recovery status for, so
  the hook no longer fabricates one. It mirrors the caller's real wallet-list
  fetch instead: loading while walletsLoading is true, then straight to
  the CTA state machine (idle). Identical behavior in every environment —
  no fake delay, no NODE_ENV branch on the status path.
• src/app/recovery/page.tsx passes useWallets().loading through as
  walletsLoading, so the loading skeleton tracks the actual /api/wallets
  request. Once a wallet resolves, the existing walletId !== null path
  (useRecoveryStatus / fetchRecoveryStatus) takes over.
• confirmRecovery keeps its existing explicit production/demo split
  (production rejects with "Select a wallet before initiating recovery.";
  non-production keeps a demo stub). Only the stale comment referencing the
  deleted bootstrap was updated. No custody secrets are ever sent — only the
  wallet identifier.

Production vs demo/mock split

Path	Behavior
walletId !== null	Real per-wallet status fetch via useRecoveryStatus; loading/error come from that fetch
walletId === null	Mirrors the real wallets fetch (walletsLoading) → idle. No simulated delay, any environment
confirmRecovery, no wallet, production	Rejects: "Select a wallet before initiating recovery."
confirmRecovery, no wallet, non-production	Short simulated success so demo dashboards work without a backend

Tests

src/hooks/__tests__/useRecovery.test.ts — reworked the stub-mode block into
a #620 block that fails if the gap returns:

• resolves straight to idle when the wallet list is not loading (no fake delay)
• stays loading while walletsLoading is true
• transitions loading → idle when the wallet list settles
• never schedules the old 1200 ms timer (spies on setTimeout)
• production tests (resolves to idle immediately; no faked success on confirm)
  retained

pnpm exec vitest run src/hooks/__tests__/useRecovery.test.ts src/app/recovery/__tests__/page.test.tsx → 50 passed. Runnable in CI via
pnpm test.

No Playwright test added: the only user-visible effect is a loading skeleton
with no live backend, and there is no recovery e2e harness.

Docs

• src/docs/API_Hooks.md — updated the useRecovery section to the new
  signature useRecovery(walletId, { walletsLoading }) and contract.
• No env changes — there are no recovery-specific vars in src/lib/env.ts.
• README's production-fallback section remains accurate (still applies to the
  confirmRecovery demo stub).

Out of scope

Backend API work (mux-backend). No new default secrets; no cookie-only auth.

Pre-existing issues (not touched)

Repo-wide tsc --noEmit errors and failing suites (recoveryApi.test.ts,
useRecoveryStatus.test.ts, RecoveryTimelineEvent/RecoveryTimelineList/
darkMode component tests) were confirmed present on a clean tree via
git stash and are unrelated to this change. Files edited here type-check and
lint clean.

[drips-wave]

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