Support some, ok and err wrappers and untyped function inputs

Track the LScript changes since the grammar was first written:

- some, ok and err are reserved prefix operators and wrapper patterns;
  the old |.some/|.ok/|.err forms and postfix/prefix ! are rejected
- function literal inputs may omit their type annotation, and tuple
  components may omit theirs; an empty typed tuple pattern is now just
  the unit pattern
- migrate fixtures, corpus, queries, CST contract and Rust tests

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

docs/cst.md

@@ -43,13 +43,33 @@ Literal leaves are named. Boolean and nil values use `boolean_literal` and
 `nil_literal`; numeric, string, character, and unit literals retain their
 specific nodes. `default_expression` is also named.
 
-`function_literal` takes one input and owns the `body` field. Direct binding
-appears as `parameter: (typed_parameter)`; tuple destructuring appears as
-`parameter: (typed_tuple_pattern)`. A `typed_tuple_pattern` contains zero or at
-least two `typed_tuple_component` nodes. These bind components of one tuple
-input, not separate function arguments. `()` matches unit; singleton tuple
-patterns are invalid. Typed bindings expose `pattern` and `type`; a header may
-also expose `effect` (`->` or `=>`) and `result`.
+`some`, `ok`, and `err` construct optional and result values. They are prefix
+operators, so `some value` and `ok {x->f}` appear as `unary_expression` nodes
+whose `operator` is the keyword. They bind like `-` and `~`, so `ok x->f`
+wraps `x` and then pipes the result into `f`, while `ok {x->f}` wraps the
+pipeline. The older `|.some`/`|.ok`/`|.err`
+constructors, postfix `value!`, and prefix `!error` are no longer accepted.
+
+`function_literal` takes one input and owns the `body` field. A pattern with
+one annotation for the whole input, such as `@ value: i32` or
+`@ (left, right): (i32, i32)`, appears as `parameter: (typed_parameter)`.
+The annotation is optional: an input whose type comes from the expected
+function type, such as `@ value` or `@ (left, right)`, is also a
+`typed_parameter` without a `type` field. Component-annotated tuple
+destructuring, such as `@ (left: i32, right)`, appears as
+`parameter: (typed_tuple_pattern)`. A `typed_tuple_pattern` contains at least
+two `typed_tuple_component` nodes, each with an optional `type`. These bind
+components of one tuple input, not separate function arguments. `()` matches
+unit and is a `typed_parameter` over a `unit_pattern`; singleton tuple patterns
+are invalid. Bindings expose `pattern` and, when annotated, `type`; a header
+may also expose `effect` (`->` or `=>`) and `result`.
+
+## Patterns
+
+`wrapper_pattern` matches `some`, `ok`, or `err` applied to one pattern atom.
+It exposes `wrapper` (the keyword) and `value` (the inner pattern). `nil` is
+still a `nil_literal` pattern. Sum patterns retain `sum_pattern` with a
+`variant` field.
 
 ## Types