feat(transport): inject CEP-15 schemaHash into tools/list results

[abhayguptas]

Summary

This PR is the next stacked CEP-15 step on top of #37.

It wires the common-schema helpers into the transport layer so opted-in tools receive _meta["io.contextvm/common-schema"].schemaHash in tools/list results. The same enrichment is applied to both direct tools/list responses and the public kind:11317 announcement content, so both paths stay consistent.

Changes

• add withCommonToolSchemas() transport helper
• add a shared tools/list result transformer seam in NostrServerTransport
• apply the same transformer before publishing kind:11317 announcement content
• export the new helper through src/transport/index.ts
• add focused unit tests for metadata injection
• add an end-to-end transport test covering direct response + announcement consistency

Tests

• bun test src/transport/server-transport-common-schemas.test.ts src/transport/nostr-server-transport.test.ts
• bun run typecheck

Notes

This PR intentionally stops at _meta.schemaHash injection and consistency between direct and announced tools/list payloads.

It does not yet add CEP-15 i / k discovery tags to announcement events. That can stay as the next follow-up PR.

[ContextVM-org]

I think the overall implementation looks good. Reusing the existing transformer path through addListToolsResultTransformer() keeps the direct and announced tools/list behavior consistent, and keeping withCommonToolSchemas() as a decorator also feels aligned with the existing withServerPayments() pattern, so I would keep that approach to avoid introducing a different configuration style just for CEP-15. I would only call out that these helpers should be treated as pre‑connect decorators, since applying them after server.connect() could lead to inconsistent announcement state. I also think there is a small cleanup opportunity in createCommonSchemaToolsResultTransformer(): the current no‑op check around mergeCommonSchemaMeta() looks ineffective because it still creates new objects, so I would prefer tightening that path to preserve immutability while avoiding unnecessary allocations when the schema hash is already present. Aside from that, the implementation looks good. Let's just keep consistency, and simplicity in mind

[abhayguptas]

Thanks, this makes sense. I kept withCommonToolSchemas() as the decorator-style API and added a note that it should be applied before connecting the transport.

I also tightened the no-op path in createCommonSchemaToolsResultTransformer() so it now returns the original result without allocating when the matching schemaHash is already present, and added focused test coverage for that case.