Investigate relay WebSocket connection reuse for injected like/zap components

[coderabbitai]

Requested by @saiy2k as follow-up work from #87.

Summary
Verify whether the injected like/zap browser extension components create one or more WebSocket relay connections per component instance while browsing X, and determine whether connection reuse or pooling is needed.

Why this matters

• Creating separate relay connections per injected button could scale poorly on busy timelines.
• Excessive WebSocket connections may hurt performance, battery usage, and relay friendliness.
• The current PR adds relay querying/publishing behavior in the browser extension and should be validated before the feature grows further.

Affected areas

• browser-extension/content.js
• Any relay access abstraction introduced later (for example lib/relays.js)
• Nostr client usage patterns and any NDK-based optimization, if applicable

Investigation tasks

• Trace when relay connections are opened for injected buttons.
• Determine whether connections are shared across posts/components or recreated repeatedly.
• Measure the worst-case number of concurrent connections on a timeline with many posts.
• Check whether existing Nostr libraries in the project already provide connection reuse/pooling.
• Propose a target architecture if reuse is missing (singleton relay manager, shared pool, lazy lifecycle, etc.).

Acceptance criteria

• Current connection behavior is documented with evidence.
• Risks and performance impact are summarized.
• Recommendation is made on whether changes are required before expanding like/zap functionality.
• If needed, a concrete implementation approach is proposed for shared relay connection management.

Backlinks

• PR: Browser extension for injecting Nostr Like buttons on X.com PoC #87
• Source comment: Browser extension for injecting Nostr Like buttons on X.com PoC #87 (comment)

[saiy2k]

This issue should be ideally solved by #105

Let's revisit once the #87 is done.