Use compact single-payload storage for LLVM variant values

## Problem

The LLVM representation of a payload variant currently stores the tag and a separate payload tuple for every case:

```text
{ i32 tag, case0_payload, case1_payload, ... }
```

This is functionally correct, but the value size grows with the sum of all case payloads. A tagged union should normally require storage for only the largest, most-aligned payload.

## Scope

- Design and implement a target-correct `tag + shared payload storage` representation, or an equivalent compact layout.
- Use LLVM target data for payload size and alignment decisions.
- Preserve zero-payload cases, generic variants, nested variants, pointer-recursive variants, constants, and statics.
- Keep direct C ABI export/import of payload variants rejected until a stable external ABI is designed.
- Document the internal layout invariant near the lowering code.

## Acceptance criteria

- Variant storage is based on the largest payload rather than the sum of all payloads.
- Tag construction, payload projection, matching, copying, constants, and statics remain correct.
- Layout and runtime regressions cover x86-64, AArch64, RISC-V 64, and WebAssembly targets.

Start by locating the LLVM variant-lowering entry points and the existing target-data layout logic. Trace tag construction, payload projection, matching, copying, constants, and statics, then inspect the layout and runtime regression coverage. Done means a target-correct largest-payload representation preserves the listed cases across x86-64, AArch64, RISC-V 64, and WebAssembly while direct C ABI exchange remains rejected.

Written by the indexing model from the issue text.