Issue 3 — Implement the EventLog record

### Context

The design doc finalizes EventLog as a record combining the raw Web3j Log fields with the decoded indexed/non-indexed parameter values:

```java
public record EventLog(
String address,
List topics,
String blockHash,
BigInteger logIndex,
BigInteger blockNumber,
String transactionHash,
BigInteger transactionIndex,
String data,
List indexedValues,
List nonIndexedValues
) {}
```

### Scope
- Implement `EventLog` exactly as specified: raw log fields (`address`, `topics`, `blockHash`, `logIndex`, `blockNumber`, `transactionHash`, `transactionIndex`, `data`) alongside `indexedValues` and `nonIndexedValues`, both `List` (Web3j's decoded ABI value type).
- Confirm the mapping from a Web3j Log to this record's raw fields is a straightforward field-for-field copy (types/names line up closely with org.web3j.protocol.core.methods.response.Log).
- `indexedValues` is populated by decoding `topics[1..]` against the indexed EventParams (#308, in declared order); nonIndexedValues by decoding data against the non-indexed EventParams. This population happens in ContractListener (#312) — this issue is about the record type itself plus any small factory/builder used to construct it from a Log + decoded Type lists.
- Note the known Solidity/Web3j limitation: an indexed string/bytes/other dynamic type only ever yields its keccak256 hash in topics, not the original value — Web3j's Type decoding for those slots will reflect that. Document this limitation on the record/factory Javadoc rather than trying to "fix" it, since it's an EVM-level constraint.

### Acceptance Criteria
- [ ] EventLog record implemented with the exact field set and types shown above.
- [ ] Unit test constructing an EventLog from a sample Web3j Log plus decoded Type lists, verifying all fields map correctly.
- [ ] Javadoc calls out the indexed-dynamic-type hash-only limitation.