revert: use chmod 770 instead of 775 for user directories

770 (rwxrwx---) is more secure - only owner and group can access, excluding 'others'.

The service user can still access because it's added to the user's group via:
  usermod -aG shellUsername serviceUser

The real fix was wrapping chmodSync in try/catch in email-db.ts so it doesn't
crash when trying to chmod files owned by other users.

src/servers/api/users/provision.ts

@@ -48,10 +48,9 @@ export async function provisionLinuxUser(email: string, username: string): Promi
   }
 
   // Set ownership and permissions on user data directory
-  // chmod 775 so the service user (in the user's group) can read/write for background jobs
-  // The service user is added to the group below, so group permissions (rwx) are needed
+  // chmod 770 so only owner and group can access (service user is added to group below)
   run(['sudo', 'chown', '-R', `${shellUsername}:${shellUsername}`, userRoot]);
-  run(['sudo', 'chmod', '-R', '775', userRoot]); // Recursive chmod to fix all subdirectories
+  run(['sudo', 'chmod', '-R', '770', userRoot]); // Recursive chmod to fix all subdirectories
 
   // Add the service user to the new user's group so server jobs can access user data
   const serviceUser = process.env.USER ?? '';
@@ -77,7 +76,7 @@ export async function provisionLinuxUser(email: string, username: string): Promi
 
   // Fix ownership and permissions after seeding
   run(['sudo', 'chown', '-R', `${shellUsername}:${shellUsername}`, userRoot]);
-  run(['sudo', 'chmod', '-R', '775', userRoot]);
+  run(['sudo', 'chmod', '-R', '770', userRoot]);
 
   console.log(`[provision] provisioning complete for ${shellUsername}`);
   return true;