[Enhancement] Implement FastCodesHeader encode/decode for SendMessageRequestHeader/ResponseHeader

### Before Creating the Enhancement Request

- [x] I have confirmed that this should be classified as an enhancement rather than a bug/feature.

### Summary

Implement `FastCodesHeader.encode()/decode()` for `SendMessageRequestHeader` and `SendMessageResponseHeader` to eliminate reflection-based header serialization.

### Motivation

`SendMessageRequestHeader` does not implement `FastCodesHeader`, so every send message request goes through `makeCustomHeaderToNet()` which uses reflection to serialize header fields into `extFields`. This creates per-RPC allocation (HashMap entries, String values from `toString()`) and CPU overhead from reflective field access.

With R1 (#10522) merged, the `FastCodesHeader` interface now provides `writeLong`/`writeInt` helpers that can write numeric fields directly without `String.valueOf()` allocation. Implementing `encode()/decode()` on send message headers eliminates the reflection path entirely.

### Describe the Solution You'd Like

Implement `encode()` and `decode()` methods on:
- `SendMessageRequestHeader` — 14 fields including Long/Integer types
- `SendMessageResponseHeader` — 5 fields
- `SendMessageRequestHeaderV2` — fix `decode()` signature to match interface

### Additional Context

Depends on R1 (#10522, merged). Related PRs: #10443, #10514, #10526.

Start by reading the FastCodesHeader interface and locating SendMessageRequestHeader, SendMessageResponseHeader, and SendMessageRequestHeaderV2. Review the merged R1 change and existing header serialization patterns, then run the relevant RocketMQ tests. Done means all specified encode/decode methods use the interface contract and the V2 decode signature matches it without the reflection path.

Written by the indexing model from the issue text.