Design a compiled Wave library artifact format

## Problem

Wave and Vex now have a source-package import contract with canonical package roots, submodules, visibility, and dependency mappings. A future compiled library artifact must preserve those module interfaces without inventing a second import syntax or depending on source checkout layout.

## Required design areas

- Artifact container and file extension, including whether `.wlib` remains the chosen name.
- Public module/interface metadata and private implementation boundaries.
- Target triple, Wave ABI version, compiler compatibility, and feature metadata.
- Native object/code payloads and multi-target packaging policy.
- Generic and language-specific type representation.
- Symbol/name-mangling information.
- Dependency identities and Vex integration.
- Reproducibility, integrity, and cache invalidation.
- Diagnostics for incompatible target, ABI, compiler, or dependency versions.

## Import contract

Source code should continue to use canonical imports such as:

```wave
import("add");
import("add::math");
import("add")::{sum, Point};
```

Vex and wavec should decide whether the dependency is satisfied from source, cache, or a compiled artifact. User source should not import an internal filename such as `lib.wave` or a separate `lib::` namespace.

## Completion criteria

- [ ] A versioned artifact specification is reviewed.
- [ ] Compatibility behavior aligns with the Wave ABI work in #350.
- [ ] Vex can select and validate a matching artifact without losing the module graph.
- [ ] Public/private visibility is preserved.
- [ ] Cross-target and generic behavior is explicitly defined.
- [ ] A minimal producer/consumer fixture is automated.

This is a design issue. Implementation should be split after the format and compatibility contract are fixed.