fix(graph): avoid superfluous GetPublicShare call when deleting space permissions

[paul43210]

Summary

• DeletePermission unconditionally called getLinkPermissionResourceID (→ GetPublicShare) as its first step, even when deleting space member permissions on space roots — producing a confusing "GetPublicShare failed" error log
• Recognise space permission IDs (u: / g: prefixed) by their format via spacePermissionIdToCS3Grantee before making any gateway calls
• Public link lookups on space roots now only happen when the ID does not match the space permission format

Fixes: #12012

Test plan

• Existing deletes a space permission as expected test updated — no longer mocks GetPublicShare (verifying it's not called)
• All 424 graph service tests pass
• Manual: remove a space member → verify no "GetPublicShare failed" error in logs
• Manual: delete a public link on a space root → verify it still works

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
59.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jvillafanez]

I'm out of the loop at the moment so I can't test and verify the solution, but code looks good.

[paul43210]

@jvillafanez Thanks for the review! Here's a quick summary:

The issue: When deleting a space-level permission (member/group grant), DeletePermission was calling GetPublicShare first to check if the permission ID belonged to a public link. This always failed for space permissions, adding a needless round-trip and returning a confusing "not found" error instead of cleanly resolving the permission type.

The fix: Space permission IDs have a distinctive format — they're prefixed with u: (user) or g: (group). We now check that format via spacePermissionIdToCS3Grantee before making any gateway calls. If it matches, we know immediately it's a space permission and skip straight to RemoveShare. Public link and user share lookups only happen for non-space-root items or when the ID doesn't match the space permission format.

What changed:

• Extracted resolveDeletePermission → resolveSpaceRootPermission / resolveItemPermission helpers (also brought SonarCloud complexity under the threshold)
• Updated the existing test to confirm GetPublicShare is no longer called for space permissions
• No behaviour change for public links, user shares, or OCM shares — those paths are untouched

[jvillafanez]

👍