fix(ddl): $value strips option<> from TYPE, breaking VALUE expressions that return NONE

[gulybyte]

$value was included in the condition that strips a leading option<> from
the DDL TYPE, assuming VALUE always produces a non-NONE value. However,
VALUE expressions can legitimately return NONE based on runtime conditions
(e.g. IF cond THEN NONE ELSE $value END).

SurrealDB natively supports TYPE option<number> VALUE ... — option<T> is
Kind::Either([Kind::None, T]), so NONE passes type validation. The DB
ultimately calls clean_none() and omits the field from the document.

Only $default and $computed keep the stripping — both always produce a
value. $value no longer strips option<>.

Fixes the case where:

s.number().optional()
  .$value(surql`IF manageStock = false THEN NONE ELSE $value END`)

Would emit TYPE number instead of TYPE option, causing:
Expected 'number' but found 'NONE'