[Bug]: Part.data set to null drops the content oneof

### What happened?

`Part` has a oneof named `content` over `text`, `raw`, `url` and `data`. `data` is a
`google.protobuf.Value`, and `null` is a perfectly good `Value`.

When `data` is null, this SDK parses the Part as having no content arm at all:

```js
import { Part } from '@a2a-js/sdk';

const p = Part.fromJSON({ data: null, mediaType: 'application/json' });
// { filename: '', mediaType: 'application/json' } no content case

Part.toJSON(p);
// { mediaType: 'application/json' }
```

`a2a-python` treats the arm as set and round-trips it:

```python
from a2a.types import Part
from google.protobuf.json_format import MessageToDict, ParseDict

m = Part(); ParseDict({"data": None, "mediaType": "application/json"}, m)
m.HasField('data') # True
MessageToDict(m) # {'data': None, 'mediaType': 'application/json'}
```

### Why it matters

"This is a data part whose payload is null" and "this part has no content" are different
statements, and the second one isn't valid. A data part sent by a Python agent arrives at
a JS peer as a Part with nothing in it, and gets forwarded on in that state.

Other `Value` shapes are fine. Objects, arrays, strings, numbers, booleans and empty
containers all round-trip identically between the two SDKs. Null is the only one that
falls through.

### What I'd expect

`{"data": null}` keeps the `data` arm set, and `toJSON` emits `data: null` rather than
omitting the key.

### How this was found

Round-tripping a shared corpus through this SDK and `a2a-python` and diffing the JSON.

Reproduced on `@a2a-js/sdk` 1.0.1 from npm and on `main` at `1c6eb32`, against
`a2a-python` at `cff6727`.

This is in the generated `src/types/pb/a2a.ts`, so happy to send the fix wherever you'd
prefer it to live.

The issue is in the generated protobuf code in src/types/pb/a2a.ts, specifically how the Part message's oneof content handles a null google.protobuf.Value. Start by examining the fromJSON and toJSON methods for the Part type. Look for the handling of the data field when its value is null. Compare with the Python SDK's behavior to understand the expected round-trip. Run the provided reproduction code to confirm the bug, then modify the generation logic or the runtime serialization to treat null as a valid Value.

Written by the indexing model from the issue text.