Removing a user does nothing, the tool puts him back from the .gpg-id files

[millaguie]

Description

There is no way to remove a user. Taking him out of .auth.yaml does not touch the
.gpg-id files, so he stays a recipient of every secret, and the next time anybody runs
any command the tool reads the .gpg-id files and puts him back into .auth.yaml. The
revocation is silently undone and the diff looks like the tool meant it.

Steps to reproduce

1. pass_collaborate group add-users alice@example.org it, she is now in .auth.yaml
   and in foo/.gpg-id
2. edit .auth.yaml by hand and remove her users: entry and her group membership
3. run any command, pass_collaborate group list is enough
4. grep alice .auth.yaml

Current behavior

She is back in .auth.yaml, as a users: entry and as a literal key in the access:
of every directory whose .gpg-id still had her fingerprint. A reencrypt then writes
her back into the .gpg-id files.

_load_gpg_id_files() is append only, anything in a .gpg-id gets promoted to
access: and nothing is ever removed, and _load_missing_users_from_keystore()
recreates the users: entry from the local keyring. So .auth.yaml can only grow.

What works today is doing it in this order, .auth.yaml first (the users: entry and
every literal fingerprint in access:), then the .gpg-id files, then reencrypt,
then check with gpg --list-packets that no .gpg is still encrypted to that key.
Cleaning the .gpg-id files without cleaning .auth.yaml first does not work.

Desired behavior

A user remove that cleans .auth.yaml and the .gpg-id files in one shot, or making
the reconciliation subtractive so .auth.yaml is the source of truth and the .gpg-id
files are generated from it. The second one is what i expected the tool to do, but it is
a bigger change.

I can send a PR, tell me which one you prefer. I saw #7 so no rush.

Environment

     pass_collaborate: 0.2.2
     Python: 3.14.6
     Platform: Linux-7.1.5-arch1-2-x86_64-with-glibc2.44