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.

[cnlohr]

In this case, I feel the distinct PID for bootloading is required. I know this isn't quite what @tannewt had mentioned in the past, but I don't see a way around it for this user. I am going to go ahead and approve.

[cnlohr]

See discussion in thread about discussion surrounding dual PID usage.

[TunalunaORG]

Thank you for taking the time to review my PR and allocating the PIDs to my project. Really appreciate your review, and glad to be part of the pid.codes family now! 🎉