[BUG] add --no-browser flag to start studio and fix standalone build compatibility

[DarshanCode2005]

Describe the bug.

Is your feature request related to a problem? Please describe.

Currently, the asyncapi start studio command automatically opens the default web browser. There is no flag exposed in the CLI to prevent this behavior, even though the underlying Studio.start() function supports a noBrowser option. This is problematic for users working in remote environments (SSH, containers) or those who simply prefer to manually open the browser.

Additionally, recent versions of @asyncapi/studio rely on a Next.js "standalone" build. The current CLI implementation does not initialize this correctly, leading to server hangs or missing static assets (404 errors) when trying to start Studio locally.

Describe the solution you'd like

1. Expose --no-browser Flag:
   Add a --no-browser flag to the asyncapi start studio command. When set, the CLI should start the server without launching the browser.

2. UX Improvements:
   When the --no-browser flag is used, the CLI output should adjust its messaging (e.g., suppress "Open this URL in your web browser") to reflect that the user is expected to open the link manually.

3. Support Standalone Builds:
   Refactor the Studio.start logic to correctly detect and run the Next.js standalone server (server.js), ensuring that public and static assets are correctly copied and served so the UI loads without 404 errors.

Describe alternatives you've considered
None. Support for the standalone build is necessary for the CLI to remain compatible with newer versions of Studio.

Additional context

• The plumbing for noBrowser already partially existed in Studio.ts but was unreachable.
• The standalone build issue manifests as the command hanging indefinitely or loading a broken page with styling/script errors.

Expected behavior

1. Running with --no-browser flag

• Command: asyncapi start studio --no-browser
• Behavior: The Studio server should start on an available port, but it MUST NOT attempt to open the default system web browser automatically.
• Output: The console should display a neutral message indicating the server is ready (e.g., 🔗 Studio is running at http://localhost:port), without the imperative instruction to "Open this URL in your web browser."

2. Standard Execution (Default)

• Command: asyncapi start studio
• Behavior: The Studio server starts, and the default system web browser opens automatically to the correct URL.
• Output: The console logs should clearly prompt the user (e.g., 🌐 Open this URL in your web browser...) and confirm the server connection.

3. Application Stability

• The Studio application should load fully without 404 errors for static assets (CSS/JS files).
• The CLI command should not hang indefinitely during startup; it must successfully initialize the underlying Next.js server (supporting the modern "standalone" build structure).

Screenshots

How to Reproduce

1. Open your terminal.
2. Run the command: asyncapi start studio --no-browser.
3. Observation: The CLI returns an error Error: Nonexistent flag: --no-browser ` and fails to start, forcing you to use the default command which opens the browser.

🖥️ Device Information [optional]

• Operating System (OS): Dual boot Windows 11 and Fedora
• Browser: Microsoft Edge

👀 Have you checked for similar open issues?

• I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines

Are you willing to work on this issue ?

Yes I am willing to submit a PR!

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[DarshanCode2005]

@Shurtu-gal Sir and @AayushSaini101 Sir, could you please give some suggestions on my implementation for this bug. In the PR I have shared the improvement video too. Thanks!