[Bug]: COM_STMT_EXECUTE accepts undefined new-parameter-bound flag values

### Summary

`COM_STMT_EXECUTE` accepts undefined values of the one-byte `new-params-bound` flag after parameter types have been established by a previous execution.

The flag has two defined states: `0` reuses the previous parameter types and `1` supplies new parameter types. MatrixOne treats every value other than `1` as `0`.

### Tested version

`main` at `8480da08f318a9cb998efb80062d5573da776fb7`.

### Reproduction

Using the frontend binary prepared-statement parser:

1. Prepare `SELECT ?`.
2. Parse one valid execution packet with `new-params-bound = 1` and a `MYSQL_TYPE_TINY` parameter. This establishes the saved parameter type.
3. Parse a second packet with `new-params-bound = 0`; it correctly reuses the saved type.
4. Parse a third packet with `new-params-bound = 2` and a one-byte value.

Minimal packet sequence used by the focused test:

```go
first := []byte{0, 1, 0, 0, 0, 0, 1, byte(defines.MYSQL_TYPE_TINY), 0, 10}
reuse := []byte{0, 1, 0, 0, 0, 0, 0, 11}
unknown := []byte{0, 1, 0, 0, 0, 0, 2, 12}
```

### Actual result

All three calls return `nil`. The undefined flag value `2` silently reuses the previously saved parameter type. The result reproduces 3/3 times.

### Expected result

Only flag values `0` and `1` should be accepted. Any other value should return an invalid-input error.

### Root cause

`MysqlProtocolImpl.ParseExecuteData` reads `newParamBoundFlag` and only checks:

```go
if newParamBoundFlag == 1 {
// read new parameter types
}
```

There is no branch that rejects values greater than `1`, so they fall through to the type-reuse path whenever `stmt.ParamTypes` was populated by an earlier execution.

This is distinct from #23979, which covered a missing flag byte rather than an undefined flag value.