fix: restrict granular project roles to Scale plan only

[HarshMN2345]

The feature was incorrectly available to Pro plan orgs. Added `$currentPlan?.group === 'scale'` guard alongside the existing supportsOrganizationRoles check in all three entry points: createMember, edit modal, and the members table action menu.

What does this PR do?

(Provide a description of what this PR does.)

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)

Related PRs and Issues

(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)

Have you read the Contributing Guidelines on issues?

(Write your answer here.)

[greptile-apps]

Greptile Summary

This PR restricts the granular/project-specific role assignment UI to Scale plan by replacing the supportsOrganizationRoles capability flag with a new supportsProjectSpecificRoles flag on $currentPlan across the three entry points where users interact with member roles.

• The guard change is applied consistently in all three places: the create-member modal, the edit-role modal, and the action-menu "Edit role" item in the members table.
• The upgrade.svelte info tooltip (rendered inside the same members page) still branches on supportsOrganizationRoles and will show the org-role description copy to Pro users, with no mention that project-specific role editing requires Scale — the intent here should be confirmed.
• supportsProjectSpecificRoles does not appear in any other file in the codebase; confirming the exact field name in the @appwrite.io/console SDK model would rule out a silent failure where the feature is hidden from Scale users too.

Confidence Score: 5/5

The change is small, consistent across all three entry points, and follows the existing pattern of gating UI on a boolean capability flag from the plan store. The main thing to double-check before merging is that the field name supportsProjectSpecificRoles matches exactly what the private SDK exposes.

The diff is a narrow, uniform substitution of one boolean field for another with no logic changes and no new code paths. No data mutation, no API calls, and no auth logic is touched. The only meaningful risk is a silent field-name mismatch in the SDK, which would show up immediately in manual testing.

Confirm the supportsProjectSpecificRoles field name in the @appwrite.io/console SDK, and review whether src/lib/components/roles/upgrade.svelte needs to be updated to reflect the Scale-only restriction on project-specific roles.

Important Files Changed

Filename	Overview
src/routes/(console)/organization-[organization]/createMember.svelte	Replaces supportsOrganizationRoles with supportsProjectSpecificRoles on $currentPlan to restrict the project-specific role UI to Scale plan
src/routes/(console)/organization-[organization]/members/+page.svelte	Same guard replacement in the action-menu "Edit role" item; the Upgrade tooltip component (which uses the separate billingPlanDetails.supportsOrganizationRoles) was not updated
src/routes/(console)/organization-[organization]/members/edit.svelte	Same guard replacement as createMember.svelte; straightforward and consistent

_{Reviews (2): Last reviewed commit: "feat: gate project-specific roles on sup..." | Re-trigger Greptile}