No error is produced if try to insert a number into a string atttibute

Describe the bug
If try to insert a number into a column, defined as string attribute, Manticore silently accepts a number, but doesn't actually insert it.

To Reproduce

RT>CREATE TABLE test4 (
    ->         `title` string attribute indexed,
    ->         `distance` string attribute indexed,
    ->         `hash` string);
Query OK, 0 rows affected (0.002 sec)

RT>INSERT INTO test4 (id,title,distance,hash) VALUES (7,'Minchinhampton Common','Unknown','17791407');
Query OK, 1 row affected (0.001 sec)

RT>INSERT INTO test4 (id,title,distance,hash) VALUES (8,'Minchinhampton Common','Unknown',17791407);
Query OK, 1 row affected (0.005 sec)

RT>select * from test4;
+------+-----------------------+----------+----------+
| id   | title                 | distance | hash     |
+------+-----------------------+----------+----------+
|    8 | Minchinhampton Common | Unknown  |          |
|    7 | Minchinhampton Common | Unknown  | 17791407 |
+------+-----------------------+----------+----------+

Expected behavior
Ideally an error msg produced. At the moment the data is accepted, but 'lost'.

A message is produced if try to insert into a column, that is ALSO a indexed field

RT>INSERT INTO manticore:test4 (id,title,distance,hash) VALUES (9,'Minchinhampton Common',17791407,'Unknown');
ERROR 1064 (42000): row 1, column 3: string expected

(ie fields check that inserting a string, string attributes don't)

OR - in fact it could just accept the number, and treat as string (same way as can technically insert a string (in quotes) into a number column)

Describe the environment:

• Manticore Search version: Server version: 5.0.0 b4cb7da0@220518 release git branch HEAD (no branch)
• OS version (uname -a if on a Unix-like system): Manticore Helm Chart 5.0.0.2

Start by reproducing the shown SQL CREATE TABLE and INSERT statements, then trace the INSERT type-validation path for string attributes. Decide whether invalid numeric input should be rejected or coerced consistently, and add coverage for the chosen behavior before verifying that the data is no longer silently lost.