Issue Summary

The dev:api script in the root package.json currently omits the @calcom/api-v2 workspace. When developers run yarn dev:api to work locally, the local API proxy starts alongside API v1. The proxy correctly attempts to route all /v2/* requests to port 3004 (as defined in apps/api/index.js), but because the NestJS API v2 server is never actually started by the root Turborepo script, those requests fail.

Steps to Reproduce

1. Run yarn dev:api in the root of the project.
2. Wait for Turborepo to boot the @calcom/web, @calcom/api, and @calcom/api-proxy workspaces.
   3.Make an HTTP request to http://localhost:3002/v2/bookings (or any v2 endpoint).
   4.The request will hang or fail because the v2 server at port 3004 is offline.

Actual Results

Requests to /v2/* through the local proxy (localhost:3002) fail by default. Developers have to manually realize they need to open a separate terminal and run yarn workspace @calcom/api-v2 dev to get the API v2 environment running alongside the rest of the stack.

Expected Results

• Running yarn dev:api should build and start the entire API stack together, including API v2. Adding --filter="@calcom/api-v2" to the dev:api script solves this seamlessly and improves local DX.

Technical details

-Framework: NestJS (API v2) & Turborepo
-The issue happens across all operating systems / browsers.

Evidence

• Evidence 1: In the root package.json, at line 39 (the dev:api script), it reads: "dev:api": "turbo run dev --filter="@calcom/web" --filter="@calcom/api-proxy" --filter="@calcom/api"" (The @calcom/api-v2 filter is missing).
  -Evidence 2: In apps/api/index.js (lines 9-16), a proxy middleware is explicitly created to proxy /v2 to localhost:3004. It's clear the intent is for V2 to be running alongside the proxy.

(If you are open to it, I can submit a quick PR to add the missing filter!)