feat(stack-encrypt)!: order floats through cllw-ore's F64 target

An `f32` or `f64` order term is cllw-ore's vitaminc encryption of the
value at the `F64` target, whose vitaminc-ore encoding folds `-0.0` into
`0.0` and every NaN into one value above `+Infinity`: Postgres's
`float8` order. So the ordering operators are now answered over floats,
on the typed path (`op::Ordered` for `f32` and `f64`) and over a data
plan's `float32` and `float64` fields, and stashgen writes `Lt`, `Lte`,
`Gt`, `Gte` and `Between` on a float field with `ore` or `ope`.

An `f32` is ordered as the `f64` it widens to: its `Orderable` target is
`F64` and vitaminc widens it exactly, so an `f32` and its `f64` are one
term and `f32` can join `op::Ordered`. That settles what the earlier
draft refused with `TermError::NarrowFloat`, which is gone. A float
`Between` is not refused when inverted (a range from NaN, which sorts
last, matches nothing), as SQL's `BETWEEN` is not.

Float pins, the float ordering baseline, the integer-width lengths and
the `score` field in the cross-path fixture carry over from the earlier
draft; the fixtures and UI snapshots are re-recorded.

Claude-Session: https://claude.ai/code/session_01BZhkvKLpNtKuzj3HCfMXoL

Author: coderdan

languages/golang/CHANGELOG.md

@@ -46,9 +46,16 @@ listed under **Breaking**. Releases are tagged `languages/golang/vX.Y.Z`.
   folded form (ADR-0002: case and accents folded, under Unicode 16), so
   `Café` and `cafe` tie and `alice` orders before `Zoe`. Text order terms
   change bytes from the alpha's; none was deployed.
+- **Ordering methods on floats.** A `float32` or `float64` field with
+  `index=ore` or `index=ope` gets `Lt`, `Lte`, `Gt`, `Gte` and `Between`.
+  Floats order as PostgreSQL's `float8` does (ADR-0002): `-0.0` ties `0.0`,
+  and every NaN is one value, above `+Inf`. A `float32` orders as the
+  `float64` it widens to. Every order term changes bytes from the alpha's,
+  now that the engine encrypts them through cllw-ore's vitaminc schemes;
+  none was deployed.
 - **stashgen notices an index no generated method queries**: an `ore` or
-  `ope` index on bytes or a float (the engine answers the orderings over
-  integers and text only), or the second of two order indexes on a field.
+  `ope` index on bytes (the engine answers the orderings over integers,
+  floats and text only), or the second of two order indexes on a field.
   The index is still stored; the notice is on stderr and in the file.
 
 ### Changed

languages/golang/cmd/stashgen/README.md

@@ -124,7 +124,7 @@ For `-type User`, the file `user_stash.go` holds:
 - `Fields`, with one entry for each sealed field.
   An opaque struct, or a struct with no sealed field outside an opaque one, gets no `Fields`: nothing in it is sealed on its own, so nothing can be queried.
   An entry encrypts one value, and has one query method for each operator the engine answers on the field: `Eq`, `Lt`, `Lte`, `Gt`, `Gte`, `Between` or `Matches`.
-  stashgen asks the embedded engine which operators each field answers, and which index answers each one, so it holds no copy of those rules: an equality index answers `Eq`, a match index on a string `Matches`, and an ORE or OPE index on an integer or a string the four orderings and `Between`, through ORE when the field declares both. A string orders by its folded form: case and accents folded, under Unicode 16.
+  stashgen asks the embedded engine which operators each field answers, and which index answers each one, so it holds no copy of those rules: an equality index answers `Eq`, a match index on a string `Matches`, and an ORE or OPE index on an integer, a float or a string the four orderings and `Between`, through ORE when the field declares both. A float orders as PostgreSQL's `float8` does (`-0.0` ties `0.0`, NaN sorts last), and a string by its folded form: case and accents folded, under Unicode 16.
   `encrypt_into=TextEq` answers `Eq`, which returns the type's query value, `eql.TextEqQuery`.
   `encrypt_into=TextMatch` answers `Matches`, which returns an `encrypt.EQLMatchQuery`: the `eql.TextMatchQuery` operand, with `Verify` and `TargetLimit`.
   The query of `Matches` carries `Verify` and `TargetLimit`, because its answer can hold rows that do not match; an exact operator's query carries neither.

languages/golang/encrypt/README.md

@@ -261,7 +261,12 @@ range matches nothing. So `Between("b", "A")` matches nothing, since `A`
 folds to `a`, below `b`. Text holding a code point Unicode 16 does not assign has no
 fold, and its query or write is refused with `encrypt.ErrTerm`.
 
-An order index on bytes or a float stores its term but answers no ordering
+Floats order as PostgreSQL's `float8` does (ADR-0002): `-0.0` and `0.0` are
+one value, and every NaN is one value, above `+Inf`, so `Between(math.NaN(),
+math.Inf(1))` matches nothing. A `float32` orders as the `float64` it
+widens to.
+
+An order index on bytes stores its term but answers no ordering
 operator, so such a field has no `Lt`; nor does the `ope` index of a field
 that declares `ore` too, since `ore` answers the orderings. stashgen prints a notice for each such index, on stderr and in
 the generated file: the terms are stored, and only your own code can compare

languages/golang/encrypt/doc.go

@@ -138,9 +138,10 @@
 // Eq returns an [EqualityTerm] (or, for a field with encrypt_into, the EQL
 // type's query value), an ordering an [OreTerm] or [OpeTerm], and Between a
 // [Range] of two. Their answers are exact. The orderings are answered on
-// integers and on text, which orders by its folded form (case and accents
-// folded, under Unicode 16), so Café and cafe tie and alice orders before
-// Zoe. Matches returns a [MatchQuery],
+// integers, on floats, which order as PostgreSQL's float8 does (-0.0 ties
+// 0.0, NaN sorts last), and on text, which orders by its folded form (case
+// and accents folded, under Unicode 16), so Café and cafe tie and alice
+// orders before Zoe. Matches returns a [MatchQuery],
 // whose answer can hold rows that do not match: size the fetch with
 // [MatchQuery.TargetLimit], then decrypt the rows and keep those
 // [MatchQuery.Verify] reports true, one call into the engine for the page.