Contributing a creature reshuffles everyone's pets: what should our policy be?

[TevvvB]

Adding a creature looks like a one-line PR and is not, and I would rather settle the policy before someone offers a cute animal and gets a wall of caveats back.

#44 documents the mechanics. Short version: a creature is drawn with pool[Hash(key) % len(pool)], so growing a band reassigns every key already in it. Measured by adding one Common:

For("main")   mouse -> toad
For("master") vole  -> toad
For("trunk")  wren  -> moth

The part that actually stings is den.json. It stores species names, internal/den calls it "the only precious state in the project", and it does not move when the roster does:

den holds "mouse" for main; Has(mouse)=true
after one new Common, main summons "toad"; Has(toad)=false

So the collection re-earns the new creature and the old entry becomes unreachable, because nothing summons it any more. Someone's month-old mouse is stranded in a file they can see and can never match again.

The question: what do we do when someone contributes a creature?

Three options I can see.

1. Batch and break, loudly. Roster growth lands in a minor release with "your pets have changed" in the notes. Cheap, honest, and the collection still gets quietly scrambled every time.

2. Never grow a band; only add bands. Adding a whole new rarity tier doesn't disturb existing pools. Preserves everything, but caps the roster at 41 forever and the new tier is the only place anything can go.

3. Make the draw insensitive to roster size. Give every species a permanent slot and draw over a fixed space, so a new creature fills an unused slot without moving anyone. Existing keys keep their creature forever and the den stays valid. It is real work, and it is the only option where "the same key yields the same creature" is actually true.

I lean 1 for now, 3 if the roster ever becomes a thing people contribute to, because 3 is only worth building once there's a queue of creatures waiting - and right now there isn't one. But I'd rather hear from anyone who has a den they care about, since option 1 spends your collection to keep the code simple.

Option 2 I'm least keen on: it makes the rarity ladder an artifact of migration history rather than a design.

If you have a creature you want in, post it here. Even under option 1 it's useful to know how big the queue is, because a batch of eight costs exactly the same disruption as one.