Express backend folded into Next.js route handlers with oRPC as the typed-RPC layer

elitan eliminated the separate backend service by relocating Express routes under the Next.js app and wiring them through an oRPC dispatcher. One process to run, one set of deps to manage - but the migration left a non-trivial HTTP compatibility shim in place.

The standalone backend package is gone. Its routes, middleware, and lib code now live under frontend/src/server/backend/, and a catch-all Next.js route handler at app/api/v1/[[...path]]/route.ts dispatches all traffic: auth requests go to better-auth, typed RPC calls go to oRPC's RPCHandler, and the former Express paths are handled by handleBackendRequest after a prefix check.

The old Hono-style route handlers weren't rewritten for Next.js. Instead, elitan added a 230-line compat.ts shim that adapts the existing handler signatures to the Fetch API's Request/Response shape. That keeps the migration tight - fewer files rewritten, lower risk of regressions - but it means anyone importing this work is also taking on a custom HTTP compatibility layer.

oRPC is introduced alongside TanStack Query on the frontend. Uploads, downloads, and SSE were deliberately left on their existing REST paths, which is a reasonable call during a cut-over.

One commit in this topic is worth filtering out. The ba3270f4 "Codex worktree snapshot" re-adds backend/src/lib/supabase.ts (which was just deleted), leaves unresolved conflict markers in README.md, and appears to be accidental Codex worktree leakage. The supabase.ts is deleted again by the folder rename that follows downstream.