First-customer readiness audit and localhost auth fix

[DevCalebR]

What was audited

• Public marketing and trust pages on localhost: /, /pricing, /simulator, /sms-consent, /start-free-pilot, /sign-up?intent=pilot
• Owner workspace flow in portfolio demo mode: /app, /app/leads, /app/leads/[leadId], /app/conversations, /app/settings, /app/billing
• Admin/operator surfaces by code and focused tests: /admin, /admin/[businessId], invite/connect, provisioning, readiness, test SMS, live proof
• Twilio webhook, SMS, message-status, voice, and status routes plus focused tests
• Billing routes, pricing copy, billing page, and Stripe readiness assumptions

What was opened locally

• http://localhost:3000/
• http://localhost:3000/start-free-pilot
• http://localhost:3000/sign-up?intent=pilot
• http://localhost:3000/pricing
• http://localhost:3000/simulator
• http://localhost:3000/sms-consent
• http://localhost:3001/app
• http://localhost:3001/app/leads
• http://localhost:3001/app/leads/lead_demo_002
• http://localhost:3001/app/conversations
• http://localhost:3001/app/settings
• http://localhost:3001/app/billing

What was fixed in this PR

• Prevent localhost from mounting broken Clerk widgets when the app is configured with live production Clerk frontend keys
• Fall back to the preview/test Clerk publishable key locally so auth pages render safely for inspection instead of failing on origin mismatch
• Move Clerk SignIn and SignUp widgets into client-only wrappers and add focused tests for the new auth behavior

What remains before first customer

• Portfolio demo lead outcome actions are still misleadingly interactive and at least Mark contacted fails with Lead not found
• Real admin/operator onboarding flow, including Invite owner by email, was not browser-verified end to end against a live admin session
• Real Stripe checkout and portal were audited by code/tests but not exercised live because of external side effects
• Real production Clerk auth acceptance flow was not fully verified locally; localhost now renders safely, but that is not the same as proving the live production auth journey

Validation

• npm install ✅
• npm run env:check ✅
• npm run preflight:providers ✅
• npm run typecheck ✅
• npm run lint ✅
• npx tsx --test tests/clerk-config.test.ts tests/public-auth-routing.test.ts tests/middleware-auth-routing.test.ts ✅
• npm run build ✅
• Full app validation was also run earlier in the main working tree with env-loaded shell state: npm run test 220/220 pass, npm run build pass, focused Twilio/admin/tenant/auth slices pass
• Note: a fresh worktree npm run test currently depends on shell-exported DB env rather than only .env.local; that is an existing local test-harness quirk, not a regression from this patch

First-customer readiness verdict

Ready only with founder supervision.

Public marketing is credible and the owner workspace direction is strong, but the demo action bug plus incomplete live admin/browser verification are still enough risk that I would not walk into a first business assuming everything is turnkey without founder-led control.

[DevCalebR]

Everything looks great.