Add noknok org + PIDs 4E4E (USB module) and 4E42 (USB bootloader)

[TunalunaORG]

Adds the noknok organization page and two PIDs for the noknok open-source modular electronics ecosystem.

PID	Title	Source repo
1209/4E4E	noknok USB module (application/runtime)	https://github.com/buildwithnoknok/module-usb-led
1209/4E42	noknok USB module bootloader (USB-CDC OTA)	https://github.com/buildwithnoknok/module-USB-bootloader

• Both PIDs are currently unallocated in the registry.
• Both source repositories are public and MIT-licensed (LICENSE file present); hardware design files are CC BY-SA 4.0.
• Project site: https://buildwithnoknok.github.io

🤖 Generated with Claude Code

[TunalunaORG]

Friendly ping — this has been open ~4 weeks with both checks passing. Happy to make any changes if something needs adjusting. Thanks for maintaining pid.codes!

[cnlohr]

@TunalunaDE Please remove claude coauthorship from your project so pidcodes doesn't get blacklisted from people with that account blocked. You may need to close this PR and open a new one.

There's also an ongoing discussion surrounding accepting PIDs for products that use a separate PID for their bootloader, instead of using a common bootloader PID. So I am going to leave this without recommendation until we get further clarification.

Recommend not merging at this time, but it need to have the dual-code question settled, as well as maybe needing to be re-opened.

❌ / ❓

[TunalunaORG]

Thanks for the review! As requested, I have removed the Claude co-authorship.

On the bootloader PID: I will not allocate one distinct PID per (future) product. I plan to use 4E4E (application) and 4E42 (bootloader) as two family-wide identities which are shared across the entire noknok USB module family. Individual modules are distinguished at runtime via a vendor command and USB serial, not by separate PIDs — so the whole ecosystem will only ever use those two shared PIDs in total.

I'm using a distinct PID for the bootloader mainly for recovery robustness: a module with dead/corrupt app firmware still enumerates unambiguously as the bootloader, so it can always be re-flashed OTA without the host having to guess its state.

I understand the fear of wasting PIDs just for a bootloader, but since I am planning to re-use the same PIDs for several products within the ecosystem, I hope this is acceptable for my case.