feat(core): basic implementation of remote workspace support

[jlongster]

Scaffolds out some core primitives we will need to allow running sessions in a remote workspace environment.

• Create a new control-plane dir
• Define a new Workspace entity stored in the db, along with some basic functions for working with them
• Introduces adaptors to support different kinds of workspace environments. This PR only adds worktree support; I have another PR that adds daytona
• Adds abilities related to communicating between local and remote env
  • A function for opening an SSE stream to listen for events from a remote env (it will do this for all workspaces within a project)
  • A forward proxy for forwarding all non-GET session-related routes to the remote env
• Wire it up so the serve command automatically starts listening to remote workspaces

Note: all of this work is flagged behind a dev flag and should not be available for any prod builds

The idea here is that we want a remote env to fully own a running session. It will have its own db with its own session (or multiple sessions). However, we want to track these sessions in the local environment, and treat them exactly the same as other sessions.

To do this, we will sync session data back from a remote env into the local env. We will have a copy of this data in both places, with the remote env acting as the writer and the local env as the reader.

The local env will present the exact same routes as it does today. But when the session is actually running in a remote env, it will forward some of the routes into the remote env.

There are two types of requests:

• get requests: these only read data. we always want to handle these in the local env based on the local sync of the session data
• everything else (post, patch, delete, put): these all mutate data. the local env should never mutate session data, it's only allowed to read it. we forward all of these to the remote env which mutates data, and that data will be synced back to the local copy

We aren't actually doing any of this syncing yet, this PR is just the groundwork for it

[OpeOginni]

Looks super cool, remind me of a small thing I did with opencode "cloud sessions" but on cloudflare sandboxes. Want to ask with daytona would the plan be to let these sandboxes stay up for a long while after initial prompt, incase users want to continue with another prompt later, or it will be able to be destroyed then a new one spins up on a new prompt?

[jlongster]

I don't love this setTimeout; it mirrors what the current worktree implementation does and is needed because the frontend assumes this will return immediately with Info and do the rest in the background. going to revisit this

[jlongster]

@OpeOginni it's up the provider, you will be able to pass provider-specific configuration, so they might let you configure it. Otherwise it's whatever guarantees they have

The reason we want to support this first-class is exactly because of the problems when a remote env shuts down. You don't your whole server to be killed along with it. We want to be able to resume the session seamlessly, recreating a new sandbox if needed, and we should be able to do that since we synced all the session data

[OpeOginni]

@jlongster Love that cant wait to see how you plug it in

[thdxr]

stupid nit but we use projectID everywhere