Permission locks (member lock, share with group lock) have incomplete enforcement and inadequate user feedback

Problem

Permission lock settings (member lock, share with group lock) have inconsistent enforcement, unclear cascading behavior, and inadequate user feedback.

Current Issues

• Incomplete enforcement - Member lock only prevents adding users to projects, NOT to the parent group. Users can bypass the lock by adding members to the group, which then inherit to projects, defeating the audit protection the setting promises.
• Stale UI state - When "share with group lock" is enabled, the Project members page still displays groups that no longer have access, with no indication they've lost access. Users see groups listed but those groups cannot actually access the project.
• Inconsistent warnings - Warning text about access loss appears in parent group settings but not in subgroup settings, causing confusion when users suddenly lose access to projects.
• Unclear cascading behavior - Documentation and UI don't clearly communicate how these settings cascade through group hierarchies, what overrides are possible, and what the actual impact is on existing access.

Root Cause

Permission locks were implemented incrementally without a cohesive model for:

• How locks cascade through hierarchies
• What entities they should block (groups vs projects vs both)
• How to communicate state changes to affected users
• How to display locked/affected state in UI

Proposed Solution

Phase 1: Fix enforcement gaps

• Member lock must block adding members at all levels (group and projects) within the locked scope
• Share with group lock must prevent new sharing and clearly invalidate existing shares
• Ensure settings cascade properly to all descendants with clear override semantics

Phase 2: Improve UI feedback

• Disable relevant, but still display buttons when locks are active (with tooltips explaining why)
• Show warnings consistently across all settings pages where locks affect behavior
• Display clear status indicators on member/group lists when they're affected by locks (e.g., "Access blocked by parent group lock")
• Remove or clearly mark groups that no longer have access due to locks

Phase 3: Clear documentation

• Document exact cascade behavior and override rules
• Provide guidance on audit use cases
• Explain relationship between different lock types