Refactor handler context to be transport- and handler-type-aware

The current RequestContext / ServerRequestContext design has a few rough edges that warrant a dedicated refactor:

1. Request vs notification context — Request handlers have request_id and meta, notification handlers do not. Currently request_id is optional (RequestId | None) on a single shared type, which loses type safety. Ideally these would be distinct types so request handlers get a context where request_id is always present, and notification handlers get one where it does not exist.

2. Transport-specific context — The request_context field on ServerMessageMetadata is typed as Any because the server layer is transport-agnostic (e.g. it is a Starlette Request for HTTP transports, None for stdio). A better design would let transports provide their own typed context that handlers can access without casting.

These two concerns are related — both point toward making the context type more precise depending on how and where a handler is invoked.

_{AI Disclaimer}

Beginne damit, RequestContext und ServerRequestContext durch die Handler-Einstiegspunkte zu verfolgen, und untersuche anschließend ServerMessageMetadata.request_context sowie die für Starlette Request und stdio erwähnten Transportfälle. Vergleiche, wie Request- und Notification-Handler Kontext erhalten und wie auf transportspezifische Werte zugegriffen wird. Als abgeschlossen gilt die Aufgabe, wenn die vorgesehenen Typgrenzen und das Transportverhalten definiert sind, ohne sich auf Any oder optionale Request-IDs zu stützen.