fix: Clarify context keys (#1309)

Author: mydea

src/docs/sdk/unified-api/index.mdx

@@ -61,11 +61,11 @@ meant that certain integrations (such as breadcrumbs) were often not possible.
 
 - **client options**: Are parameters that are language and runtime specific and used to configure the client. This can be release and environment but also things like which integrations to configure, how in-app works etc.
 
-- **context**: Contexts give extra data to Sentry. There are the special contexts (user and similar) and the generic ones (`runtime`, `os`, `device`), etc.  Check out <Link to="/sdk/event-payloads/contexts">Contexts</Link> for valid keys. *Note: In older SDKs, you might encounter an unrelated concept of context, which is now deprecated by scopes*
+- **context**: Contexts give extra data to Sentry. There are the special contexts (user and similar) and the generic ones (`runtime`, `os`, `device`), etc.  Check out <Link to="/sdk/event-payloads/contexts">Contexts</Link> for some predefined keys - users can also add arbitrary context keys. *Note: In older SDKs, you might encounter an unrelated concept of context, which is now deprecated by scopes*
 
 - **tags**: Tags can be arbitrary string→string pairs by which events can be searched. Contexts are converted into tags.
 
-- **extra**: Truly arbitrary data attached by client users.  This is a deprecated feature but will continue to be supported for the foreseeable future.  Users are encouraged to use contexts instead.
+- **extra**: Truly arbitrary data attached by client users. Extra should be avoided where possible, and instead structured `context` should be used - as these can be queried and visualized in a better way.
 
 - **transport**: The transport is an internal construct of the client that abstracts away the event sending. Typically the transport runs in a separate thread and gets events to send via a queue. The transport is responsible for sending, retrying and handling rate limits. The transport might also persist unsent events across restarts if needed.