family.py add does not ask whether the member's project.yaml id is one the family already pins, so adding a repository renamed at the forge (same id, new name) commits a holder that validate-family.py then refuses as member-duplicate-id #330

Lane: openreposhape-3 (openRepoShape-3)

What happens. cmd_add compares the new member's repository and project name with the existing rows (family.holding, which #221 made case-blind), mounts it, then reads its project.yaml id, and never compares that id with the rows'. Measured on be2790e: a scaffolded project testorg/Atlas (id atlas) and a bare copy of it as testorg/Atlas2 (same id), both in a local remote directory, added in turn to a family holder:

family.py add --member testorg/Atlas  ...   committed 63798239159d: .gitmodules, members/Atlas, family.yaml
family.py add --member testorg/Atlas2 ...   committed f8fd25fa57e3: .gitmodules, members/Atlas2, family.yaml
validate-family.py --no-members             FINDING member-duplicate-id: Atlas2 and Atlas both record id 'atlas': one project is pinned twice.   exit 1

Where. scripts/family.py:cmd_add (:823; the id comes from _read_member_project after git submodule add); templates/family-root/scripts/validate-family.py:_check_member_ids_unique (:525), the validator that refuses it afterwards.

Why it matters. add writes a commit its own gate rejects, and the holder then fails CI. The check belongs before the mount: #236 (open, for #203) adds a pre-mount probe that reads project.yaml from a throwaway clone, which is where this refusal fits; placed after the mount today, a refusal would leave exactly the staged mount #203 is about. So implement it after #236 lands.

Source. PR #221, ## Left out, first bullet. Related: #203 (open), #206 (closed).