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}

Bắt đầu bằng cách lần theo RequestContext và ServerRequestContext qua các điểm vào của handler, sau đó kiểm tra ServerMessageMetadata.request_context và các trường hợp transport được đề cập cho Starlette Request và stdio. So sánh cách các handler request và notification nhận context cũng như cách truy cập các giá trị riêng của transport. Hoàn tất khi các ranh giới kiểu dự kiến và hành vi của transport được xác định mà không phụ thuộc vào Any hoặc các request ID tùy chọn.