flat path: a narrow enum payload used in an expression emits unparseable MLIR

An enum whose variants carry integers of different widths gets one payload slot, sized for the widest variant. On the flat path a narrower variant's payload can be returned, but not used in an expression.

enum Pick<T> {
  Narrow(i8),
  Wide(T),
}

impl<T> Pick<T> {
  fn narrow_or(self : Pick<T>, d : i64) -> i64 {
    match self {
      Pick<T>::Narrow(n) => { return n as i64; }
      Pick<T>::Wide(w) => { return d; }
    }
  }
}

fn main() -> i32 {
  print(Pick<i64>::Narrow(-3 as i8).narrow_or(0));
  return 0;
}

use of value '%v10' expects different type than prior uses: 'i64' vs 'i8'
[flat-codegen] program outside the flat subset; using the AST path

In a release build the flat path declines and the AST fallback gives the right answer. In the test profile it exits 101 instead, so the program compiles through neither path.

What narrows it down:

• return n; on its own is fine -- the payload only has to be used for this to appear. A comparison such as n < (0 as i8) fails the same way, so it is not about the cast.
• A payload the same width as the slot is fine, so it is the width difference that matters.
• The AST path handles all of these correctly as of the change that added tests/optimizations/pass/enum_payload_narrower_variant.vx.

That fixture is on the AST path and is listed in KNOWN_BROKEN in tests/integration_test/flat_corpus_sweep.rs because of this.

Related: #570 sized the slot from the first variant rather than the widest.

Start with tests/optimizations/pass/enum_payload_narrower_variant.vx and trace the flat-codegen path that handles its narrower enum payload. Run the fixture and tests/integration_test/flat_corpus_sweep.rs; done means the fixture compiles through the flat path without the MLIR type error and can be removed from KNOWN_BROKEN while retaining the correct AST-path behavior.