stack-encrypt: dynamic control messages (plan, options, query results) are parsed from an untyped FfiValue tree — give each its own type, and stop eql-bindings forcing dynamic #1252

Background

Stack Encrypt (packages/stack-encrypt) is CipherStash's Rust encryption engine. Rust programs use it through typed structs and derives. Other languages use it through stack_encrypt::dynamic, a module behind the off-by-default dynamic feature. That module describes values whose types are known only at run time. Today its one production user is the Go SDK's WebAssembly guest (languages/golang/encrypt/guest).

Everything crosses between the Go host and the guest as a vitaminc frame: a self-describing byte encoding of one value. Since #1245, plaintext crosses as a frame and stays one. The engine walks it in place (Frame, ValueFrame) and never decodes it into a tree.

Problem

1. The control messages still use a general-purpose value tree. Everything that is not plaintext is decoded into FfiValue, an untyped tree of nulls, numbers, strings, bytes, arrays and objects, and then picked apart by hand. Each message has a fixed shape, so a general tree buys nothing. Verified on the feat(stack-encrypt,golang): give every Go integer width, dates, timestamps, decimals and 128-bit integers their own kinds #1246 branch:

   Direction	Message	Where
   In	record plan	dynamic::record::plan / plan_with (dynamic/record.rs:926)
   In	a field's encryption context, for se_term and se_keyset	dynamic::context (dynamic/context.rs:97)
   In	an index in a plan's outputs, and an output entry	IndexSpec::from_value (dynamic/term.rs:99), Output::from_value (dynamic/record.rs:201)
   In	query statistics, for the target limit	Stats::from_value (dynamic/query.rs:964)
   In	call options (keyset, expected context)	guest options.rs
   In	cipher configuration, including the client key	guest config.rs
   In	the deterministic test seed	guest abi.rs
   Out	query term result	QueryTerm::to_value (dynamic/query.rs:344)
   Out	verify results, the target limit	guest ops.rs, limit_to_value (dynamic/query.rs:1027)
   Out	EQL type and operator catalogues	TargetDescriptor::to_value (dynamic/target.rs:150), operator_to_value (dynamic/query.rs:518)

   The cost:

   • Every message is checked by hand. Each parser walks the tree, matches variants and refuses unknown keys, repeated keys and wrong types on its own. That is most of record.rs's plan parser.
   • The tree can hold secrets. The cipher configuration carries the client key, so FfiValue has to wipe its text and byte leaves. A typed message would hold the key in one Protected field.
   • It reads like a plaintext type. FfiValue looks like a general value, so it gets used as one (see the next item). Since feat(stack-encrypt)!: hold a dynamic plaintext as its frame, not a value tree #1245, plaintext must never be one.

2. eql-bindings' tests use FfiValue as a plaintext constructor. eql-bindings' own API takes ValueFrame, and nothing outside its tests uses FfiValue. Its tests build frames with ValueFrame::of(&FfiValue::Int32(-7)) and read opened values back with FfiValue::from_frame. That happens in crates/eql-bindings/src/encryption/targets.rs (unit tests) and tests/encryption/tests/{targets,v4_types,heap_hygiene}.rs (around 80 uses). This is the role feat(stack-encrypt)!: hold a dynamic plaintext as its frame, not a value tree #1245 says FfiValue no longer has, and it leads readers to think eql-bindings depends on it.

3. eql-bindings turns on dynamic for every user of its encryption. Its stack-encrypt feature depends on stack-encrypt with features = ["dynamic"]. Only the by-name dispatch that a guest needs (encryption/targets.rs, v4/targets.rs) uses dynamic. The typed v4 types (IntegerEq, TextEq, …) do not. A Rust program that encrypts an IntegerEq through encrypt_as still compiles the whole dynamic layer. Pure Rust consumers should never need it.

Proposal

1. Cheap first step: stop using FfiValue in eql-bindings' tests. Build frames from Rust values directly (ValueFrame::of(-7i32), ValueFrame::of("café")). Compare an opened frame against ValueFrame::of(expected) byte for byte.
2. Split eql-bindings' feature. stack-encrypt gives the typed EQL v4 types only, with stack-encrypt's default features off and no dynamic. A new feature (for example targets) adds the by-name dispatch and turns on stack-encrypt/dynamic. The Go guest and tests/encryption enable it. eql-bindings is published to crates.io, so note the change in its CHANGELOG.
3. Give each control message its own type, read straight from the frame. Follow the vitaminc ADR 0001 pattern: each message type is a Decrypt sink, or reads a Frame walk, so no tree is built. Each output is an Encrypt source written by FrameWriter. Start with the small messages (options, stats, query result, catalogues, seed). Do the plan last, since it has the largest grammar. Each type refuses an unknown key, a repeated key or a wrong type with the Reason it reports today. The configuration holds the client key in Protected.
4. Remove FfiValue from stack_encrypt::dynamic once nothing uses it, including FfiValue::to_frame/from_frame and the guest's decode_value/encode_value/value_encoded_len. Pin each message's bytes with a fixture that the Go host's tests read too.

Relationship to other work

• stack-encrypt: the Go guest still copies record plaintext into an FfiValue tree — walk frames into vitaminc sinks instead #1232: the plaintext half of this, handled by feat(stack-encrypt)!: hold a dynamic plaintext as its frame, not a value tree #1245 (records, query inputs and opened values are frames).
• stack-encrypt: delete dynamic::Value and Scalar, derive terms through vitaminc, add block ORE, drop Bool order terms #1140: removed the older dynamic::Value and Scalar types.
• Go guests return only a status number on failure — add se_last_error carrying the full error as an FfiValue, with a leak test #1100: se_last_error. Check whether its error payload is one more control message to type.