Small updates needed to Clan documentation

[Hectate]

@Rimek86 I thought drop some feedback on things I noticed.

1. A clan has a profil which includes... << "profile" is misspelled.
2. Invited players can accept invitiation by [aclan/cceptInvite](https://github.com/beyond-all-reason/tachyon/blob/master/docs/schema/clan.md#acceptinvite) << aclan/cceptInvite the 'a' is moved out of the correct place.
3. Only the clan-leader is able to kick members << This explicitly excludes co-leaders. Is that correct?
4. What is expected to happen if clan/kickMember is used on one's self? Is that an invalid_request failure?
5. Is clan/setRole also used to demote a coLeader back to member? We should explicitly say if so or not.
6. I dislike that clan/setRole does double-duty as a "promote" and "promote and also vacate self as leader" request. We could separate these actions in the client for safety, but I feel like having a separate setLeaderRole request that explicitly will also demote yourself is better. Just a thought.
7. After a self-demotion from leader role, what is the former leader's role? Are they a coLeader or just a member? We should explicitly say which.

[Rimek86]

@Hectate Thank's for the feedback.

To 3: Yes. I thought that co-leaders are able to configure the clan and accept new member. But only the leader is able to kick someone. Want to try this way but maybe it's change after a trial phase of the new feature.
To 4: Yes. It will be an invalid_request
To 5: Yes. Also a co-leader can be resetted to a normal member.
To 6: I have to think about....
To 7: New role is member. Leader and coleader are nearly the same. The leader (current idea) is the only one who is able to delete the clan and kick member. But everything else (i thought) is identically with the coleader permissions. (Maybe if we change your suggestion of no. 3 the only extra permisson of the leader is to delete the clan....)

[Hectate]

Some other thoughts as I'm still reading through this.

8. Your links (in the top doc) are cancelInvite, acceptInvite, and declineInvite but the actual implementation is just cancel, accept, and decline, so they don't take the reader to the right place.
9. The clan/accept would be nice if it had a failure reason of invite_cancelled so we can explicitly tell the user that the invite was no longer valid when they accepted it. This is not likely possible unless the server is going to maintain a list of invalid invitation pairs (clanID <> userID) or something. Otherwise all we will get is a general failure and have to infer that either something went wrong in code or the invite was no longer valid.
10. There is no way for a co-leader or leader to get a list of currently outstanding invitations. We probably need something like clan/viewInvites that returns a list of UserIDs that have unaccepted invites. That would allow us in the client to manage outstanding invitations. A nice-to-have feature would be also knowing which leader/coleader created the invite.

[dl-alexandre]

Hi @Hectate, I've submitted PR #2 in my fork that addresses all the documentation feedback you provided in this issue.

Summary of Changes

✅ Fixed typos:

• 'profil' → 'profile'
• 'aclan/cceptInvite' → 'clan/acceptInvite'

✅ Clarified permissions:

• Kick: Both leader AND co-leaders can kick (not just leader)
• Self-kick: Documented as returning 'invalid_request' error
• Demotion: Documented that setRole can demote co-leader to member
• Leadership transfer: Clarified former leader becomes co-leader

📝 Note on item #6: The suggestion to separate setRole into distinct commands (setRole vs setLeaderRole) is a design proposal that might be better suited as a separate feature request issue.

All changes were made to and the documentation has been regenerated. Ready for review!

[Rimek86]

Hi @Hectate, I've submitted PR #2 in my fork that addresses all the documentation feedback you provided in this issue.

Summary of Changes

✅ Fixed typos:

* 'profil' → 'profile'

* 'aclan/cceptInvite' → 'clan/acceptInvite'

✅ Clarified permissions:

* Kick: Both leader AND co-leaders can kick (not just leader)

* Self-kick: Documented as returning 'invalid_request' error

* Demotion: Documented that setRole can demote co-leader to member

* Leadership transfer: Clarified former leader becomes co-leader

📝 Note on item #6: The suggestion to separate setRole into distinct commands (setRole vs setLeaderRole) is a design proposal that might be better suited as a separate feature request issue.

All changes were made to and the documentation has been regenerated. Ready for review!

Thank's for this doc fixes.

[Rimek86]

@Hectate I’ve started working on the remaining items in this issue and have given point 6 (setLeaderRole) some more thought:
To be honest, I don’t see any reason to create an additional schema or command here. I don’t see any security benefits here. Security must come from checking in the client beforehand whether you have the appropriate role to assign a new role to the user. In case of doubt, this would also need to be verified on the server side. However, in my opinion, the protocol shouldn’t be responsible for that. Where exactly do you see an advantage in separating this?

[Rimek86]

@Hectate Why i can not link my PR (Draft) to this Issue? (I think it's wrong the the PR of @dl-alexandre closes this whole issue...)

[Hectate]

@Hectate Why i can not link my PR (Draft) to this Issue? (I think it's wrong the the PR of @dl-alexandre closes this whole issue...)

Not sure what was going on for your side, but I went ahead and linked it to this from the PR.