fix: allow users to open projects with accessible environments

[Konders]

What is this PR about?

This PR fixes a bug where users with restricted environment access (e.g., only development but not production) couldn't open projects because the application always tried to navigate to the default environment. The fix ensures that when opening a project, we first try the default environment if accessible, otherwise fall back to the first accessible environment. This makes the permission system work as intended and allows users with restricted access to still work with projects they have permission to view.

Checklist

Before submitting this PR, please make sure that:

• You created a dedicated branch based on the canary branch.
• You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
• You have tested this PR in your local instance.

Issues related (if applicable)

Fixes #3394

Changes Made

Core Fix

Updated the environment selection logic in three locations to handle users without access to the default environment:

1. Search Command (apps/dokploy/components/dashboard/search-command.tsx):

   • Changed from finding default environment from full list to finding it from accessible environments
   • Falls back to first accessible environment if default is not accessible
   • Updated comment to clarify the behavior

2. Projects List (apps/dokploy/components/dashboard/projects/show.tsx):

   • Replaced productionEnvironment lookup with accessibleEnvironment that uses fallback logic
   • Ensures project cards link to environments users can actually access

3. Server-Side Redirect (apps/dokploy/pages/dashboard/project/[projectId]/environment/[environmentId].tsx):

   • Added logic to redirect users to accessible environments when they try to access an inaccessible one
   • Tries to find default accessible environment first, otherwise uses first accessible
   • Better UX than redirecting to home page

Technical Details

The backend already filters environments correctly - the project.all query returns only environments the user has access to for members. The issue was that the frontend code didn't account for this filtering and still tried to find the default from what it assumed was the full list.

The fix is straightforward: since the environments array is already filtered for members, we select from that filtered list. We try the default first (if it exists in the accessible list), otherwise we grab the first one available.

Testing

Added comprehensive test coverage in apps/dokploy/__test__/env/environment-access-fallback.test.ts:

• 13 test cases covering all scenarios
• Tests default environment selection when accessible
• Tests fallback to first accessible when default is not accessible
• Tests edge cases (no environments, null/undefined, multiple defaults, etc.)
• All tests passing ✅

Backward Compatibility

This change is fully backward compatible. Users who have access to the default environment will see no change in behavior. The fix only improves the experience for users with restricted access.

Testing Instructions

To verify the fix:

1. Create a project with production (default) and development environments
2. Create a member user with access only to development environment
3. Log in as that user and verify:
   • Can open project from projects list → opens to development
   • Can open project from search command → opens to development
   • Direct URL to production environment → redirects to development
   • Users with access to production still open to production (backward compatible)