feat(transport): expose inbound Nostr request event id in MCP requests

[ContextVM-org]

Add support for injecting and accessing the inbound Nostr request event ID in MCP request messages via the _meta field. This enables middleware and tools to access the original Nostr event that triggered the request, including the event's pubkey and full event data through a request-scoped context store.

[1amKhush]

Hey, thanks for putting this up! Being able to access the original Nostr event in middleware is going to be super useful (for things like audit logging)

I took a look through the code and the overall approach looks solid. I did notice a few things we might want to tweak before merging:

The main thing is around nostrRequestContexts in the new nostr-request-context.ts file. Since it's a module-level Map, it'll be shared across all transport instances in the same process. Even though event ID collisions are basically impossible, this breaks instance isolation and could make tests a bit flaky if state leaks between runs (majorly i think this would be a concern for running tests as tests cannot isolate state, if a test forgets to clean up or if it fails mid-way) . Do you think we could scope this map to the transport instance instead? (Maybe keep it as a private property on NostrServerTransport or pass it into the CorrelationStore). If we really need it to be a global ambient context, we should probably at least add a clear() export to use during teardown/testing.

A couple other minor thoughts:

• Opt-in injection: We're currently injecting requestEventId unconditionally. Since we made injectClientPubkey opt-in via a flag, should we do the same here to keep the API consistent and avoid bloating _meta for people who don't need it?
• Redundant getters: getNostrRequestEvent and getNostrRequestContext do exactly the same thing right now. Unless you're planning to make getContext return a bigger object later, we can probably just drop one to keep the API surface smaller.
• Dropped messages: If an inbound middleware decides to drop a message (by not calling forward()), the event context gets left in the map until the LRU eventually evicts it. It's not a huge deal since the LRU bounds the memory leak, but it would be a lot tidier to handle it.

Lmk what you think!

[ContextVM-org]

Thanks @1amKhush for your review. Attached your comments. Mergin