improvement(http1): robustness of request header parsing in req/header.go

## Description

While reviewing the HTTP/1.1 request header parsing code in
`pkg/protocol/http1/req/header.go`, I found several places where
defensive checks or small adjustments could make the code more robust
and RFC-compliant.

## Issues Identified

### 1. `parse()` sets RawHeaders before confirming ReadRawHeaders succeeded

`parse()` line 131 calls `h.SetRawHeaders(rawHeaders)` before checking
if `ext.ReadRawHeaders()` returned an error. When the read fails, it
unnecessarily mutates header state before bailing out.

https://github.com/cloudwego/hertz/blob/main/pkg/protocol/http1/req/header.go#L130-L13
6

### 2. Missing empty-buffer guard in `parseFirstLine()`

When `buf` is empty, the method-char validation loop (`for i, c := range buf`)
becomes a no-op and falls through. An explicit `len(buf) == 0` guard makes
the control flow immediately obvious and is a standard defensive practice.

https://github.com/cloudwego/hertz/blob/main/pkg/protocol/http1/req/header.go#L163-L17
6

### 3. Degenerate `n=0` path in `ReadHeaderWithLimit()`

When `r.Len()` returns 0, `n` becomes 0, and the next
`tryReadWithLimit(h, r, 0, ...)` peeks 0 bytes (degenerate path).
Setting `n=1` when `r.Len()` returns 0 keeps the reader blocking for
incoming data, which is the clearer and more correct behavior.

https://github.com/cloudwego/hertz/blob/main/pkg/protocol/http1/req/header.go#L90

### 4. Conflicting Content-Length values silently accepted

RFC 7230 Section 3.3.2 requires that messages with multiple Content-Length
headers with **different** values MUST be rejected as invalid. Currently
Hertz silently overwrites the first value with the second (last-one-wins),
which is non-compliant and could mask bugs in upstream proxies or clients.

https://github.com/cloudwego/hertz/blob/main/pkg/protocol/http1/req/header.go#L260-L27
3

## Proposed Changes

1. **`parse()`**: Move `h.SetRawHeaders(rawHeaders)` to after the error check
2. **`parseFirstLine()`**: Add `if len(buf) == 0 { return 0, err }` before the loop
3. **`ReadHeaderWithLimit()`**: Add `if n == 0 { n = 1 }` after `n = r.Len()`
4. **`parseHeaders()`**: After parsing a duplicate Content-Length, compare with
the existing value. If different, store `err` and set contentLength to -2
(using the existing error-accumulation pattern in `parseHeaders`).
Identical duplicate values are accepted (RFC compliant).

## Impact

- Changes 1–3 are pure defensive improvements with **zero behavioral change**
for valid inputs
- Change 4 introduces a behavioral change: **only HTTP/1.1 requests that are
already invalid per RFC 7230** (conflicting Content-Length) are rejected
instead of silently accepted

## Hertz Version

v0.10.3

## Additional Context

The same issues exist in the response header parser at
`pkg/protocol/http1/resp/header.go` (particularly Content-Length conflict
detection and the n=0 path), which could be addressed in a follow-up PR.

I have a working branch ready and would like to open a PR if the
maintainers are interested.

---