feat: Add mobile-friendly /link2/{id} endpoint with caching and security limits

[SeverinAlexB]

The current main branch is a copy of the pubky-core http-relay which was used for testing before. The goal is to extract this library to clean up the core repo.

This branch tries to solve #2 by adding caching. It also adds features to make the code more mature for a production environment.

Summary

• Add /link2/{id} endpoint with response caching and shorter timeout to support mobile clients that may be backgrounded or killed during requests
• Add security limits: max body size, max pending requests, max cached entries, max channel ID length
• Refactor single-file implementation into modular structure under src/http_relay/
• Add comprehensive CLI options for all configurable parameters
• Add OpenAPI specification and improved documentation

Test plan

• Verify /link endpoint still works as before (10 min timeout, no caching)
• Test /link2 endpoint with 25s timeout and verify cache works on retry
• Test security limits reject oversized payloads and return 503 when at capacity
• Test channel ID length limit (256 bytes max)
• Create a example pubky sdk login app and test on mobile browsers

Code Quality

This repo is fully vibe coded. I double checked the important areas but let me know if you want me to unslop things.

[86667]

Im probably missing some context, im wondering out loud:
Shall we just replace link with the link2 behaviour and pull out 50% of the code and information in this repo? I understand that we're fixing some mobile timeout issue due to connection being dropped, and link2 expects for the caller to retry the call after 25s.
But if the current link behaviour is timing mobile clients out at 30s anyway, is 25s that much of a downgrade?

[SeverinAlexB]

I am currently completely redoing link2 with #3 . The new PR uses explicit acks. I explain everything later when the PR is ready.

I don't think our current http-relay has a 30s timeout. I think we increased it explicitly so at least we dont run in to this specific timeout issue. The reason link1 is still here is that we have backwards compatibility with the old SDKs. The new PR but also link2 have a new url path so they will not work. So I do think it's worth keeping them.

Do I make sense?