Prepare three-Worker Cloudflare staging deployment

[gilbertsahumada]

The web now builds with OpenNext for Cloudflare Workers and delegates business requests to the Hono API through a Service Binding. A separate Queue/Cron Worker runs the shared research runtime. The backend Workers have no public HTTP route, and initial deployments keep admissions closed.

This is the third sequential PR, based on #25 (which depends on #24 and #23). It preserves the public frontend design while correcting signup/demo text that implied wallet creation or automatic betting. It adds deployment configuration, CI Worker builds, topology checks, local Supabase product-schema configuration, and staging/rollback instructions. Each file has its own commit.

Validation:

• 243 tests passed against isolated local Supabase databases, including migration histories, identity isolation, leases and PostgreSQL budgets.
• Format, lint and all ten workspace type checks passed.
• Web/OpenNext, API and research Worker builds passed.
• Browser validation ran against compiled local Workers and real local Supabase: waitlist/application cookie and form, signup/profile/workspace, pending operator approval, two users with separate agents, queued research polling, pause, schedule rejection before validation, and logout.
• No paid model/provider acceptance call was made. The local consumer remained disabled.

This PR remains draft because remote acceptance is incomplete. Dedicated Supabase staging access is not available yet; Hyperdrive IDs remain explicit local-build placeholders. No staging URL or remote deployment is claimed. Before ready-for-review: provision dedicated resources, verify cache-disabled Hyperdrive, configure secrets and HTTPS auth, deploy from an identified commit, and complete the capped two manual plus one scheduled research acceptance. See docs/cloudflare-staging.md and docs/cloudflare-local-validation.md.

No automatic merge, production deployment, legacy Durable Object deletion, or PR #22 trading integration.