Fix Bug: Sandbox onboarding ignores API validation errors and shows generic failure message

[biisal]

📋 Summary

Related Issue: Fixes #10868
Improves error handling when creating a sandbox organization by parsing and displaying specific API validation errors instead of a static fallback message.

🎯 What

• Replaced the hardcoded error message in the sandbox organization creation step with dynamic parsing of createError.detail.
• Added logic to handle both array-based validation errors (reading the first msg) and direct string errors from the API.
• Preserved the original generic message ("Failed to create organization. Please try again.") as a fallback if the error format doesn't match expected patterns.

🤔 Why

Previously, if sandbox organization creation failed (for example, due to a taken slug or other API validation errors), the user would only see a generic "Failed to create organization. Please try again" message. This change ensures that any specific API validation errors are properly passed through and displayed to the user, making it much easier for them to understand what went wrong and fix it without getting stuck.

🔧 How

1. In the onSubmit handler of SandboxStep.tsx, updated the if (createError) block.
2. Extracted the actual error string by checking if createError?.detail is an array (taking the first msg property) or a string.
3. Passed the extracted message to the existing setError state updater so it renders correctly in the SubmitButton.

🧪 Testing

• I have tested these changes locally
• All existing tests pass (uv run task test for backend, pnpm test for frontend)
• I have added new tests for new functionality
• I have run linting and type checking (uv run task lint && uv run task lint_types for backend)

Test Instructions

1. Start the local development server for the web app (pnpm run dev in clients/apps/web).
2. Navigate to the sandbox onboarding setup (/onboarding/sandbox).
3. Attempt to submit the form under a condition that will trigger a backend validation error (e.g., using an organization name/slug that you know already exists).
4. Verify that the form correctly displays the specific API error text from the backend instead of the generic fallback.

🖼️ Screenshots/Recordings

Before changes

After Changes

📝 Additional Notes

✅ Pre-submission Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my code
• I have commented my code where necessary
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have updated the relevant tests
• All tests pass locally (excluding pre-existing mock issues)
• AI/LLM Policy: If I used AI assistance, I have tested and executed the code locally (not just "vibe-coded")

[sebastianekstrom]

Thanks for fixing this!

[sebastianekstrom]

@biisal could you please adress the formatting issues reported by the CI? Thank you!

[biisal]

Fixed! Should be good to go now 😊

[sebastianekstrom]

@biisal Thanks! Could you also revert the changes to .vscode/settings.json? Or was there a reason for the change?

[biisal]

@sebastianekstrom Actually, those files were getting hidden in the sidebar for me (and other VS Code forks), which made it pretty difficult to navigate the project while working from the root folder.

I commented them out to make development easier, but should I revert this? If there's a specific reason for hiding the server, clients, and docs folders in the workspace config, I'm happy to move these settings to my local user profile instead