docs: correct the Python and Go event data model tip

The Python/Go tip in the streaming events reference described a single
`Data` class/struct with every field optional, where fields that are not
populated for an event come back as `None`/`nil`. Both bindings use a
separate data type per event, so code written against that tip does not
work: in Go `event.Data` is the `SessionEventData` interface and reading a
field off it does not compile, and in Python `event.data` is a per-event
dataclass, so reading a field that belongs to another event raises
`AttributeError` instead of returning `None`.

The tip was accurate when it was added and went stale when both bindings
moved to per-event data types. Describe the per-event model instead, using
the wording the same file already uses for .NET, and correct the copy of
the same sentence that the docs style guide uses as its example of a
language-qualified callout.

Author: examon

.github/instructions/docs-style.instructions.md

@@ -49,7 +49,7 @@ When a callout applies to a specific language, put the qualifier as bold text in
 
 ```markdown
 > [!TIP]
-> **(Python / Go)** These SDKs use a single `Data` class/struct with all fields optional.
+> **(Python / Go)** These SDKs use separate, per-event data types.
 ```
 
 ## Lists

docs/features/streaming-events.md

@@ -210,7 +210,7 @@ session.on(AssistantMessageDeltaEvent.class, event ->
 </details>
 
 > [!TIP]
-> **(Python / Go)** These SDKs use a single `Data` class/struct with all possible fields as optional/nullable. Only the fields listed in the tables below are populated for each event type—the rest will be `None` / `nil`.
+> **(Python / Go)** These SDKs use separate, per-event data types (e.g., `AssistantMessageDeltaData`), so only the relevant fields exist on each type.
 >
 > [!TIP]
 > **(.NET)** The .NET SDK uses separate, strongly-typed data classes per event (e.g., `AssistantMessageDeltaData`), so only the relevant fields exist on each type.