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`. A float `Between` is not refused
when inverted (a range from NaN, which sorts last, matches nothing), as
SQL's `BETWEEN` is not.

The Go query profile gains a sealed `Score float64` with ORE, matching
the Rust query fixture, and the live PostgreSQL test stores the score and
its ORE term so the rows it reads back open. Float pins, the float
ordering baseline, the integer-width lengths and the `score` field in the
cross-path fixture are added; the fixtures and UI snapshots are
re-recorded.

Closes #1236.

Author: coderdan

languages/golang/CHANGELOG.md

@@ -75,9 +75,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

@@ -216,14 +216,14 @@ or a type defined over one (`type Email string`):
 | `int8`, `int16`, `int32`, `int64`, `int` | an integer of the field's own width (`int` is 64-bit) | `equality`, `ore`, `ope` | `Eq`, `Lt`, `Lte`, `Gt`, `Gte`, `Between` |
 | `uint8` (`byte`), `uint16`, `uint32`, `uint64`, `uint` | the same, unsigned | `equality`, `ore`, `ope` | the same |
 | `encrypt.Int128`, `encrypt.Uint128` | a 128-bit integer | `equality`, `ore`, `ope` | the same |
-| `float32`, `float64` | a float of its width | `equality`, `ore`, `ope` | `Eq` |
+| `float32`, `float64` | a float of its width | `equality`, `ore`, `ope` | `Eq`, `Lt`, `Lte`, `Gt`, `Gte`, `Between` |
 | `encrypt.Decimal` | a decimal: a 96-bit coefficient and a scale up to 28 | `equality` | `Eq` |
 | `encrypt.Date` | a calendar date | `equality` | `Eq` |
 | `time.Time` | a timestamp, to the nanosecond, in UTC | `equality` | `Eq` |
 
 Each query method needs its index declared. An `ore` or `ope` index on bytes
-or a float stores its term, but the engine answers no ordering through it
-yet, so such a field has no `Lt` (see [Queries](#queries)).
+stores its term, but the engine answers no ordering through it, so such a
+field has no `Lt` (see [Queries](#queries)).
 
 `encrypt.Date`, `Int128`, `Uint128` and `Decimal` are vitaminc's `vcvalue`
 types; build them with `encrypt.DateOf`, `ParseInt128`, `ParseUint128` and
@@ -238,8 +238,8 @@ width, and each width is passed to the order scheme as itself, so an `int8`
 field's terms are an `int8`'s. Equality follows vitaminc's normalisation: an
 integer equals itself at every width, decimals compare at any scale
 (`1.50 = 1.5`), and a timestamp compares to the microsecond. An order index on
-a decimal, date or timestamp is refused for now: those order terms wait for
-new cllw-ore and ore-rs releases (#1236).
+a decimal, date or timestamp is refused for now: the engine derives no
+order term for those kinds yet.
 
 A `match` index stores text with no token (an empty string, separator-only
 text, or text shorter than the n-gram length of 3 characters) as the empty
@@ -297,7 +297,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

@@ -153,9 +153,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.