Add a verb to remove/un-adopt a workspace member

[mostlydev]

Problem

There's no inverse of gnit adopt. Once a repo is registered as a member, the only documented way to stop tracking it is to hand-edit .gnit/roster.yaml — which the skill guidance explicitly discourages ("Do not hand-edit .gnit/ machinery").

This comes up in a real workflow: you adopt a repo, then realize it shouldn't be a workspace member (e.g. its lifecycle is independent of the rest of the workspace — per-customer config that shouldn't be pinned against product versions). You want to keep the clone on disk but take it out of gnit.

gnit ignore doesn't cover it

gnit ignore <path> looked like the tool for this, but on a path that is currently a member it does not un-adopt — it appends the path to the ignored: list while leaving the members: entry in place, producing an inconsistent roster where the same path is both a member and ignored:

members:
  - id: dicom-printer-configs
    path: dicom-printer-configs
    remote: https://github.com/.../dicom-printer-configs.git
    required_excludes:
      - dicom-printer-configs
ignored:
  - dicom-printer-configs

gnit status still lists it as a member after gnit ignore.

Repro

git clone <url> configs
gnit adopt configs          # now a member
gnit ignore configs         # adds to ignored: but member entry remains
gnit status                 # still shows configs as a member

What I'd expect

A first-class verb, e.g. gnit remove <path> (a.k.a. un-adopt / detach), that:

• removes the member from roster.yaml
• cleans up the gnit-managed required_excludes / .git/info/exclude entry as appropriate
• leaves the member's working tree and its own .git untouched on disk (it's just no longer a workspace member)
• auto-commits the .gnit/ metadata change like adopt does (with --no-commit to opt out)
• optionally a flag to simultaneously add it to ignored: (the common "keep it here but stop tracking it" case)

It might also be reasonable for gnit ignore on an existing member to either refuse with a clear message ("X is a member; run gnit remove first") or to perform the member→ignored transition atomically, rather than silently producing a dual-listed roster.

Workaround used

Reverting the adopt commit conflicts once anything else has touched roster.yaml (e.g. a later gnit ignore appended an ignored: block), so a plain git revert of the adopt isn't reliable. I ended up hand-editing roster.yaml to drop the member block (keeping the ignored: entry) and committing manually — exactly the hand-edit the guidance warns against, which is why a real verb would help.

Observed on gnit 0.9.1 (commit 98b81cc).