[Bug]: COM_STMT_EXECUTE accepts truncated iteration-count for zero-parameter statements

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

- [x] I have checked the existing issues.

## Branch Name

main

## Commit ID

e538e203ad47ebf0506a424fe93aed61290c4061

## Actual Behavior

`MysqlProtocolImpl.ParseExecuteData` validates the one-byte cursor flag and then advances `pos` by four bytes for `iteration-count` without checking that those bytes exist.

For a prepared statement with zero parameters, there is no later read that can detect the truncation. Payloads containing only 1, 2, 3, or 4 bytes (all shorter than the required flag plus four-byte iteration count) therefore return success.

The relevant code is `pkg/frontend/mysql_protocol.go:833-847`.

## Expected Behavior

Every `COM_STMT_EXECUTE` payload shorter than the mandatory fixed header must be rejected as a malformed packet, including statements with zero parameter markers.

## Steps to Reproduce

1. Prepare `select 1` through the binary protocol.
2. Call `ParseExecuteData` with `data := make([]byte, n)` for each `n` from 0 through 4; when `n > 0`, set the cursor flag byte to zero.
3. Observe that `n == 0` returns an error, while `n == 1`, `2`, `3`, and `4` return `nil`.

Minimal invariant:

```go
for n := 0; n < 5; n++ {
err := proto.ParseExecuteData(ctx, proc, stmt, make([]byte, n), 0)
require.Error(t, err)
}
```

## Additional information

This is not the truncated `new-parameter-bound-flag` case fixed under #23979. That check is reached only when parameters exist; this bug is the unchecked fixed iteration-count field and is observable specifically with zero-parameter statements.