Fix destructive collection permissions for shared users

[cursor]

Summary

• fixed a critical authorization bug where users with shared/grant-only access could rename or delete entire collections
• tightened canRenameOrDeleteCollection to allow destructive operations only for owner and creator access states
• added regression tests in src/server/access/collections.test.ts to ensure grants/non-members cannot perform destructive actions

Bug and impact

Grant recipients (users shared onto a collection but not owners/creators) were treated as eligible for rename/delete. Those operations can move or remove all objects under a collection prefix, causing major user-facing breakage and potential data loss.

Root cause

canRenameOrDeleteCollection returned state.kind !== "none", which accidentally granted destructive privileges to grant state.

Fix and validation

• changed permission check to state.kind === "owner" || state.kind === "creator"
• added unit tests covering allowed and denied states
• validated with test run:
  • npm test ✅ (4 files, 20 tests passing)