bug: inconsistently-shaped `instances` from `Translate` and `Validate`

[mildwonkey]

This is very hard to describe in prose, so here's an example! https://github.com/mildwonkey/thema-examples/tree/main/translate

Here's the incredibly simplified, pseudocode tl;dr:

i0, _ := sch.Validate(exdata)
title, _ := i0.Underlying().LookupPath(cue.ParsePath("title")).String()
fmt.Println(title) // "foo"

i1, _ := i0.Translate(thema.SV(0, 1))
title1, err := i1.Underlying().LookupPath(cue.ParsePath("title")).String()
fmt.Println(err) // #Translate.out.result.result: field not found: title

The title field is unchanged and should be accessible with the same Underlying().LookupPath method.

[sdboyer]

Thanks for the issue!

A little more from debugging, we see this output along these lines when calling fmt.Fprintf("%#v") on the cue.Value returned from cue.Value returned from Instance.Underlying():

_#def
_#def: *{
    _accum[i].result
    schdef._#schema
} | INST.#x

//cue:path: #Translate.inst
let INST = {
    #x: {
        title: "foo", ...
    }
}

It looks like our current tests for translate (both vmux tests and this txtar) didn't catch this because they look only at what happens when the cue.Value here is exported/forced to concreteness, so that it can be encoded as JSON or into a Go struct or whatever. That causes all of these internals to collapse to the expected concrete value, resulting in passing tests.