#4562: fix(nostr): use dispatchReplyFromConfig for inbound messages

The Nostr channel was calling a non-existent handleInboundMessage method on the plugin runtime. This refactors the onMessage handler to use the correct API pattern: - Build proper MsgContext with all required fields - Finalize context with finalizeInboundContext - Record session metadata with recordInboundSession - Create reply dispatcher with createReplyDispatcherWithTyping - Dispatch to agent with dispatchReplyFromConfig This follows the same pattern used by Matrix, MS Teams, and Mattermost channel extensions. Fixes #4547 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates the Nostr inbound DM handler to follow the standard channel pipeline used by other extensions: resolve an agent route, build/finalize an inbound `MsgContext`, record session metadata, create a reply dispatcher (with no-op typing hooks for Nostr), and dispatch via `dispatchReplyFromConfig` instead of calling a non-existent `handleInboundMessage` API. Overall the refactor aligns Nostr with Matrix/Mattermost/Teams patterns and should restore inbound message handling; the main area to double-check is the `MsgContext` addressing fields (`To`/`OriginatingTo`) to ensure routing/session keys and reply targeting behave as intended for DMs. <h3>Confidence Score: 4/5</h3> - This PR is likely safe to merge, with one DM addressing detail to verify. - Change is localized to Nostr inbound handling and follows established patterns from other channel extensions; the main risk is subtle behavior changes if `MsgContext.To`/`OriginatingTo` are expected to reference the peer/room rather than the bot account id, which could affect session routing or replies. - extensions/nostr/src/channel.ts (verify `To`/`OriginatingTo` semantics for Nostr DMs) <!-- greptile_other_comments_section --> _{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!} <!-- /greptile_comment -->