fix(router): NIP-11 being served only on root instead of relay path

[sagar-h007]

Description

This PR fixes an issue where the NIP-11 relay information document was only being served at the root (/) of the domain, even when the relay itself was configured on a different path (for example /v1).

Specifically, this PR introduces the following changes:

• Adds a top-level request interceptor that checks for Accept: application/nostr+json.
• Routes matching requests to the NIP-11 handler regardless of the path.
• Updates the NIP-11 handler to use flexible header matching (includes instead of strict equality).
• Normalizes header checks to avoid issues with compound or case variations.

Related Issue

#381

Motivation and Context

According to the NIP-11 spec, the relay metadata should be available on the same URI that handles the WebSocket connection. In practice, this means a relay at wss://domain.com/v1 should expose its NIP-11 document at https://domain.com/v1, not just at https://domain.com/.

Previously, WebSocket upgrades in Nostream were effectively path-agnostic, while Express routes were explicitly bound to /. As a result, requests like GET /v1 with Accept: application/nostr+json returned a 404 instead of the expected NIP-11 response. This change keeps the fix minimal while aligning behavior more closely with the NIP-11 spec and how relays are typically exposed behind proxies or path prefixes.

How Has This Been Tested?

Tested locally by verifying that NIP-11 is now correctly served on the relay path (e.g., /v1). Verified that the existing behavior on the root (/) remains unchanged and that the updated handler successfully processes requests from real-world clients sending compound Accept headers.

Test run:

curl -H "Accept: application/nostr+json" http://localhost:8008/v1

Types of changes

• Non-functional change (docs, style, minor refactor)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my code changes.
• All new and existing tests passed.

[cameri]

Can you elaborate a bit why we can't use a strict equality check here?