fix: data_editor corrupting int8/uint8/float16 columns on edit - #10211

… (#10304)

**This pull request was authored by a coding agent.**

## What / why

Editing a cell in a **pandas `float16`** column silently corrupts the
whole column: the edited value is stored as a string and the column
dtype flips to `object`.

```python
import pandas as pd
from marimo._plugins.ui._impl.data_editor import apply_edits

df = pd.DataFrame({"a": pd.array([1.0, 2.0, 3.0], dtype="float16")})
apply_edits(df, {"edits": [{"rowIdx": 0, "columnId": "a", "value": "5.5"}]})
# before: dtype object, values ['5.5', 2.0, 3.0]   (corrupted)
# after:  dtype float16-compatible numeric, values [5.5, 2.0, 3.0]
```

#10211 addressed `int8`/`uint8`/`float32` by switching to
`dtype.is_integer()` / `dtype.is_float()`, but `float16` still degrades:
narwhals (2.x) has no `Float16`, so it reports pandas `float16` as
`nw.Unknown`. Both predicate checks return `False` and `_convert_value`
falls through to `return str(value)`. The dtype-preservation test the PR
added for `float16` is currently **red on `main`**:

```
FAILED tests/_plugins/ui/_impl/test_data_editor.py::test_apply_edits_dataframe_small_width_numeric_preserves_dtype[float16]
```

## Fix

For an unsupported/`Unknown` dtype, fall through to the existing
original-value coercion (`_convert_value` already handles
`int`/`float`/`str`/…) instead of stringifying. For a numeric column the
original value is a Python `float`/`int`, so the edit stays numeric.
This is a superset fix — any dtype narwhals can't classify but whose
values are numeric now round-trips correctly.

## Tests

- The previously-failing
`test_apply_edits_dataframe_small_width_numeric_preserves_dtype[float16]`
now passes.
- Added `test_convert_value_unknown_dtype_coerces_from_original`, which
pins the fall-through directly against `nw.Unknown` (independent of
narwhals' evolving float16 mapping).
- `pytest tests/_plugins/ui/_impl/test_data_editor.py` → 107 passed;
`ruff check`/`ruff format` clean.

Follow-up to #10211.

…o-team#10211)

### What / why

Editing a cell in a numeric column whose dtype is `Int8`, `UInt8`,
`Int128`, `UInt128`, or `Float16` silently corrupted the column.
`_convert_value` hand-enumerated only the 16/32/64-bit integer and float
widths, so any other width fell through to `return str(value)`:

- **pandas** — the edited value became a string and the whole column was
coerced to `object`.
- **polars** — the edit failed with a misleading `ValueError: Data
editor does not support this type of data`.

```python
import pandas as pd
from marimo._plugins.ui._impl.data_editor import apply_edits
df = pd.DataFrame({"a": pd.array([1, 2, 3], dtype="int8")})
res = apply_edits(df, {"edits": [{"rowIdx": 0, "columnId": "a", "value": "5"}]})
print(res["a"].dtype, list(res["a"]))
# before: object ['5', 2, 3]   (corrupted)
# after:  int64  [5, 2, 3]
```

### Fix

Replace the hand-enumerated width lists with narwhals' dtype-category
predicates (`dtype.is_integer()` / `dtype.is_float()`), which cover
every integer/float width and can't miss one again. The category methods
are used rather than adding `nw.Int8`/`nw.Float16` explicitly because
`nw.Float16` does not exist as an attribute on the minimum supported
narwhals (2.0.0), so referencing it would `AttributeError`.

### Tests

Added direct `_convert_value` tests (Int8/UInt8/Int128/UInt128/Float16)
and dataframe-level dtype-preservation tests (pandas int8/uint8/float16
+ polars Int8). All fail on the previous code and pass now. `pytest
tests/_plugins/ui/_impl/test_data_editor.py` → 105 passed; `ruff
check`/`ruff format` clean.

Fixes marimo-team#10210

…o-team#10211) (marimo-team#10304)

**This pull request was authored by a coding agent.**

## What / why

Editing a cell in a **pandas `float16`** column silently corrupts the
whole column: the edited value is stored as a string and the column
dtype flips to `object`.

```python
import pandas as pd
from marimo._plugins.ui._impl.data_editor import apply_edits

df = pd.DataFrame({"a": pd.array([1.0, 2.0, 3.0], dtype="float16")})
apply_edits(df, {"edits": [{"rowIdx": 0, "columnId": "a", "value": "5.5"}]})
# before: dtype object, values ['5.5', 2.0, 3.0]   (corrupted)
# after:  dtype float16-compatible numeric, values [5.5, 2.0, 3.0]
```

marimo-team#10211 addressed `int8`/`uint8`/`float32` by switching to
`dtype.is_integer()` / `dtype.is_float()`, but `float16` still degrades:
narwhals (2.x) has no `Float16`, so it reports pandas `float16` as
`nw.Unknown`. Both predicate checks return `False` and `_convert_value`
falls through to `return str(value)`. The dtype-preservation test the PR
added for `float16` is currently **red on `main`**:

```
FAILED tests/_plugins/ui/_impl/test_data_editor.py::test_apply_edits_dataframe_small_width_numeric_preserves_dtype[float16]
```

## Fix

For an unsupported/`Unknown` dtype, fall through to the existing
original-value coercion (`_convert_value` already handles
`int`/`float`/`str`/…) instead of stringifying. For a numeric column the
original value is a Python `float`/`int`, so the edit stays numeric.
This is a superset fix — any dtype narwhals can't classify but whose
values are numeric now round-trips correctly.

## Tests

- The previously-failing
`test_apply_edits_dataframe_small_width_numeric_preserves_dtype[float16]`
now passes.
- Added `test_convert_value_unknown_dtype_coerces_from_original`, which
pins the fall-through directly against `nw.Unknown` (independent of
narwhals' evolving float16 mapping).
- `pytest tests/_plugins/ui/_impl/test_data_editor.py` → 107 passed;
`ruff check`/`ruff format` clean.

Follow-up to marimo-team#10211.