[Enhancement✨] Reconsider RequestHeaderCodec V1/V2 retention before 1.0

Current Behavior

#9730 and #9732 preserve RequestHeaderCodec (V1) and RequestHeaderCodecV2 as deprecated public derives throughout the 1.x series, with removal deferred to an explicit 2.0 breaking window.

The latest published release is still v0.9.0, while main is already versioned as 1.0.0 and no v1.0.0 tag exists. RequestHeaderCodecV3 was introduced after v0.9.0 in #8962. The current migration inventory reports 153 registered headers, 153 V3 headers, zero V2 headers, and zero pending migrations, and the production protocol source contains no V1 or V2 derive use.

Public GitHub code searches did not identify an independent downstream consumer of the V1 or V2 derives; the only results outside this repository were a source-corpus copy of this repository. This does not rule out private or unindexed consumers, but the current 1.x retention policy creates a long-lived compatibility commitment before the first release that contains V3.

Proposed Enhancement

Reconsider the V1/V2 retention decision before the v1.0.0 release:

• If there are no known downstream compatibility requirements, remove the deprecated V1 and V2 derive entry points and their legacy implementation surface before 1.0.
• Update the compatibility tests and fixtures, structural public API freeze, migration guide, macro documentation, and changelog so V3 is the single supported request-header derive.
• Preserve the existing V3 wire contracts and the behavior of all registered production headers.
• If known downstream requirements justify retaining V1/V2, record that rationale and keep the compatibility policy established by #9732.

Benefits

• Uses the natural 0.9-to-1.0 breaking boundary instead of deferring cleanup until 2.0.
• Avoids carrying deprecated parsing quirks, compatibility adapters, tests, documentation, and API-governance exceptions throughout 1.x without an identified consumer.
• Gives the 1.0 public API a single request-header derive model and a clearer migration story.
• Makes the compatibility trade-off an explicit release decision rather than an implicit consequence of the earlier guard work.

Additional Context

• #9730 originally added the retirement guard and closed when #9732 was merged.
• The release-boundary question was raised afterward in #9730, but the issue was already closed.
• Relevant repository paths include rocketmq-macros/src/lib.rs, rocketmq-doc/en/release/1.0/api-migration.md, and rocketmq-protocol/tests/fixtures/request_header_codec/migration.json.
• V1 and V2 were public in v0.9.0, so removal should remain an explicit maintainer decision even though no independent public downstream use was found.

Start by reading rocketmq-macros/src/lib.rs, the migration guide at rocketmq-doc/en/release/1.0/api-migration.md, and rocketmq-protocol/tests/fixtures/request_header_codec/migration.json, then review the compatibility tests and public API freeze. Done means maintainers have chosen removal or retention, with the relevant implementation, tests, fixtures, documentation, and changelog updated while V3 behavior remains unchanged.