[Opt][Reliability] Contain numeric conversion errors from statistic responses

### Environment Setup

VIDEX Version: `8cad1b0f07236bc9067afcc36765b35d736e0a14` (current `main` as of 2026-08-22)
Database: MySQL and MariaDB plugin implementations
Deployment Mode: Plugin calling the statistic server
Audit environment: Windows 10; source-level verification of both plugin implementations

### Observed vs Expected Behavior

Both plugins parse successful statistic-server responses into string maps and then call throwing `std::sto*` conversions directly, without a surrounding conversion-error boundary.

Representative current paths include:

- MySQL: `ha_videx.cc` lines 787, 816, 909, 924-925, 953, 991, 1038 and 1362
- MariaDB: `ha_videx.cc` lines 678, 854, 863-867 and 908
- The simple response parsers accept the response structure/message and expose the data values as strings; they do not validate each value against the target numeric type before these conversions.

A response can therefore be structurally valid and report `message: "OK"` while one statistic is non-numeric, negative for an unsigned field, or outside the target type's range. `std::stoul`, `std::stoull`, `std::stof` and `std::stod` then throw `std::invalid_argument` or `std::out_of_range`.

Actual behavior from the source path:

```cpp
n_rows = std::stoul(res_json["stat_n_rows"]);
stats.data_file_length = std::stoull(res_json["data_file_length"]);
rec_per_key_float = std::stof(res_json[concat_key.c_str()]);
```

No caller around these plugin request/assignment paths catches those exceptions and translates them into an `HA_ERR_*` result or a conservative statistics fallback.

Expected behavior:

Malformed, incompatible, or out-of-range statistic values should be rejected at the protocol boundary and should produce the plugin's documented error/fallback behavior rather than letting a C++ exception escape the storage-engine callback.

### Impact

A statistic-server version mismatch, corrupted response, or unexpected numeric value can terminate the current optimizer/plugin operation instead of degrading safely. The same reliability boundary exists in both MySQL and MariaDB implementations.

### Why this report has no PR

A complete patch needs decisions about the expected fallback for every affected handler path, consistent range rules for signed/unsigned and floating values, and regression coverage inside supported MySQL and MariaDB source trees. The audit environment does not contain those database source trees or a supported Linux plugin build/runtime, so a cross-engine patch could not be compiled or integration-tested safely.

Suggested validation for a fix: inject a structurally valid `message: "OK"` response with one invalid or out-of-range statistic into each plugin test harness, verify no exception escapes, and assert the selected `HA_ERR_*` or conservative fallback result.

Start with the listed std::sto* conversion sites in the MySQL and MariaDB ha_videx.cc implementations, then inspect their response parsers and plugin request/assignment handlers. Add harness cases for structurally valid OK responses containing invalid or out-of-range statistics in both implementations. Done means no exception escapes and each case produces the selected HA_ERR_* result or conservative fallback.

Written by the indexing model from the issue text.