fix(components): FilterBuilder 值控件按「无值」而非「假值」判空,三处键入数值读数收敛到严格判定 (#4873, #4875)

#4873:`!condition.value` 与 `String(condition.value || "")` 把布尔 false 与
数字 0 当成没填 —— 控件显示 placeholder / 空框,行却带着、存着、按着这个值筛。
「无值」收成一处判定(undefined / null / ''),四个显示站点与两个既有正确站点
共读。

#4875:三处 parseFloat(raw) || 0 改走 convertScalarToFamily 的严格读数 ——
'42abc' 不再落成 42、'acme' 不再落成 0。读不出数在单值/区间是「没填」,
在 token 输入是拒绝提交并保留草稿。今天被 number 输入框挡着,收敛防口径漂移。

Co-authored-by: Claude <noreply@anthropic.com>

Author: claude

.changeset/filter-builder-falsy-values-and-strict-numeric-reads.md

@@ -0,0 +1,36 @@
+---
+'@object-ui/components': patch
+---
+
+`FilterBuilder` shows the falsy values a row actually holds — a boolean `false` and a number `0` are values, not empty boxes.
+
+The value controls asked `!condition.value` and `String(condition.value || "")`,
+which folds `false` and `0` in with the rows nobody has filled in yet. Both rows
+saved, persisted and filtered by their value the whole time; only the control
+said otherwise:
+
+- a boolean column filtered `equals false` snapped back to the **Select value**
+  placeholder the moment the user clicked **False**, while the row carried
+  `value: false`;
+- a number column filtered `equals 0` showed an empty box — and typing `0` into
+  one looked like the keystroke had never landed, because the row took the value
+  and the very next render blanked the input;
+- a single-select whose option id is `0` showed the placeholder too, even though
+  the same control's multi-select branch already drew that option as checked.
+
+"No value" is now one judgement (`undefined` / `null` / `''`), read by every
+value control and by the two helpers that already spelled it out correctly, so
+"not picked yet" and "picked False" stay two distinguishable states rather than
+trading places.
+
+The three keyed numeric paths — the token input's commit, a range bound, and the
+single value input — no longer read with `parseFloat(raw) || 0`, which takes half
+of `"42abc"` and turns `"acme"` into `0`: a filter the user never wrote. All
+three now use the same strict reading a field switch uses, so this component
+holds one answer to "is this string a number" instead of a strict one and a
+lenient one. An unreadable entry becomes an unfilled value, except in the token
+input, which declines the commit and leaves the text in the draft box to be
+fixed. No behaviour a user can reach today changes: those inputs are
+`<input type="number">`, which never hands a non-numeric string to the component
+in the first place — this closes the drift, before a text box, a formula or a
+paste path opens it.