[Bug]: multiple content oneof arms are silently accepted instead of rejected

### What happened?

More than one member of a oneof being present is malformed input, and proto3 JSON treats
it as an error. `a2a-python` does:

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

ParseDict({"text": "hello", "url": "https://example.com/x"}, Part())
# ParseError: Message type "lf.a2a.v1.Part" should not have multiple "content" oneof fields
```

This SDK accepts it and picks one:

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

Part.toJSON(Part.fromJSON({ text: 'hello', url: 'https://example.com/x' }));
// { text: 'hello' } url is gone, no error
```

### Why it matters

Which arm survives is decided by the order fields are assigned in the generated
`fromJSON` body, not by anything in the input. So a malformed message from a buggy peer
gets silently reinterpreted rather than refused, and the two SDKs can end up disagreeing
about what the sender meant. Silently is the part that bothers me: whoever sent it gets
no signal that half their Part was discarded.

### What I'd expect

`fromJSON` throws when more than one member of `content` is present, matching what
`a2a-python` and the proto3 JSON mapping do.

### 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`.

Generated code again, so let me know where you'd want the fix.

The issue is in the generated `fromJSON` method for the `Part` type. Look at the generated code for the `Part` message, likely in a file like `src/generated/a2a.ts`. Find where `fromJSON` assigns fields from the input object. The fix is to add validation that only one field from the `content` oneof is present before assignment, throwing an error if multiple are found. Test by creating a test case that passes an object with both `text` and `url` and expects an error, and verify the fix matches the Python SDK's behavior.

Vom Indexierungsmodell aus dem Issue-Text verfasst.