[Bug]: truncated COM_STMT_CLOSE and COM_STMT_RESET packets enter panic recovery

### Is there an existing issue for the same bug?

- [x] I have checked the existing issues. Closed issue #23977 concerns prepared-statement state cleanup and missing statement handling, not truncated command packets.

### Branch Name

`main`-based checkout (`main`)

### Commit ID

`e538e203ad47ebf0506a424fe93aed61290c4061`

### Actual Behavior

The `COM_STMT_CLOSE` and `COM_STMT_RESET` branches decode a statement ID with `binary.LittleEndian.Uint32(data[0:4])` without first checking `len(data) >= 4`.

A packet with 0-3 bytes panics with `slice bounds out of range`. The top-level recovery prevents the process from crashing, but it returns a non-nil Go error and constructs a response for `COM_QUERY`, so the protocol-level response is associated with the wrong command.

White-box tests using a three-byte payload reproduce the panic/recovery path for both commands.

### Expected Behavior

Truncated `COM_STMT_CLOSE` and `COM_STMT_RESET` packets should be validated before decoding and return a normal protocol error response for the original command without entering panic recovery.

### Steps to Reproduce

For each of `COM_STMT_CLOSE` and `COM_STMT_RESET`:

1. Create a minimal frontend session and command executor.
2. Call `ExecRequest` with payload `[]byte{1, 2, 3}`.
3. Observe the recovered `slice bounds out of range` error and the response command being `COM_QUERY`.

### Relevant code

- `pkg/frontend/mysql_cmd_executor.go`: `ExecRequest` COM_STMT_CLOSE branch
- `pkg/frontend/mysql_cmd_executor.go`: `ExecRequest` COM_STMT_RESET branch