Four identity states here, three chip type ids in the RFID guide — say which is which

[BenGlut]

docs/concepts/universal-filament-identity.md describes four states of the identity: TigerData → TigerData+ → TigerTag → TigerTag+.

The RFID guide knows three chip type ids: TigerTag (0x5BF59264), TigerTag+ (0xBC0FCB97) and TigerTag Init (0x6C41A2E1, the factory blank marker). It never mentions TigerData.

Neither is wrong. One describes the lifecycle of the record, the other what is written on silicon. But nothing anywhere says so, so readers reconcile them by guessing — a community member published a three-state model because of exactly this.

To do here:

• state explicitly that the four states are states of the identity and the type ids are states of the chip;
• document TigerTag Init, which this repository never mentions.

Related, and blocking part of it: now that the + (catalogue product ID) and the signature are two separate layers, the guide's type-id table needs a ruling — what type id does an unsigned TigerTag+ carry? That decision belongs in the guide's repo and affects readers already in the field.

[BenGlut]

Ruling from @BenGlut — the type id question is settled.

All TigerTag+ chips carry the same type id, 0xBC0FCB97, whether they are signed or not. Certification does not change the id: a certified manufacturer writes a valid signature, and that is the only difference. A reader determines whether a chip is a TigerTag+ Certified by checking the signature area (pages 0x18–0x27), not by looking at the type id.

Nothing changes for the 2.5 million chips already in the field, and no reader needs to learn a new id.

This unblocks the corresponding work in TigerTag-RFID-Guide, whose type-id table currently describes 0xBC0FCB97 as "same offline data, plus ECDSA signature and a cloud product ID" — bundling the two layers that are now separate.