vector types · phase 5: vectors in structs and across FFI

Phase 5 of docs/discussions/design-vector-types.md (Section 5a).

• Ordinary structs: allowed, at the datalayout's natural alignment. No frontend-side layout rule is added beyond giving layout.rs a Simd arm; field_info has none today (src/layout.rs:180-195), so a struct with a vector field currently declines.
• Test the layouts agree. !llvm.struct<(f32, vector<4xf32>)> measures 32 bytes with the vector field at offset 16, measured through mlir-translate --mlir-to-llvmir (design Section 11.2 item 4). The frontend's offset must equal it. This is the test that keeps decision 7's one-alignment invariant honest, and it matters because the frontend computes layouts rather than querying a datalayout (Section 11.5 item 2): scalar_size_align derives from ElementType::bits() and a pointer field is a hardcoded (8, 8). The only datalayout in the tree is a string attached to the module for the target (src/driver.rs:969-988).
• extern "C" structs: refused in the first cut, with a diagnostic. The C ABI for vector members is target-specific and not worth guessing before there is a user.
• By-value vector parameters or returns across extern "C": refused in the first cut. Pass by pointer.

The two refusals are the same policy already applied to tensor fields in extern "C" structs: refuse rather than silently pick a layout.

Blocked on Vx#478.

Read docs/discussions/design-vector-types.md Section 5a, then inspect src/layout.rs:180-195 and the target datalayout handling in src/driver.rs:969-988. Use mlir-translate --mlir-to-llvmir to compare the ordinary-struct layout, and review the existing tensor-field policy for extern "C". Done means vector layouts agree with LLVM and both extern C refusals produce diagnostics; the work is blocked on Vx#478.