fix(vaden_mcp): remove spurious initialized notification on startup

[tecrodrigocastro]

Summary

This fixes two related JSON-RPC protocol violations in vaden_mcp that break strict MCP clients (observed with Claude Desktop, which rejects both messages with a Zod invalid_union schema error).

1. Spurious server-initiated initialized notification on boot

• vaden_mcp sent a bogus initialized message to stdout immediately on startup, before any client request.
• Per the MCP spec, notifications/initialized is sent by the client after the initialize handshake completes — never by the server on boot. The message was also missing the notifications/ prefix.
• Removed the startup notification and the now-unused _sendNotification helper. Server info is still returned correctly via the initialize response handler (_handleInitialize).

2. Server responded to notifications it didn't recognize

• _handleRequest treated every incoming message as a request. When the client sent a notification (no id field, e.g. the client's own notifications/initialized) for a method not in the switch statement, it fell into the default case and got an unsolicited error response with id: null.
• Per JSON-RPC 2.0, notifications must never receive a response, regardless of whether the method is recognized. id: null also doesn't fit the schema's expected string | number id, compounding the failure.
• Added an isNotification check (message has no id) so the server no longer replies to notifications in the unknown-method and internal-error paths.

Test plan

• dart analyze on vaden_mcp — no new issues
• dart test in vaden_mcp — all 3 existing tests pass
• Manually piped initialize → notifications/initialized → tools/list → resources/list into dart run bin/vaden_mcp.dart — stdout now contains only the correct responses, in order, with no extraneous or invalid messages
• Verified against Claude Desktop's MCP log locally: the exact sequence that previously produced the ZodError: invalid_union now completes cleanly