Model target link and runtime capabilities in TargetSpec

## Problem

`TargetSpec` records architecture, OS, object format, and a single `hosted` boolean. As Wave adds musl, FreeBSD, Windows variants, WebAssembly, and freestanding targets, that flag cannot express whether a target supports only IR/object emission, default linking, sysroot discovery, bundled CRT, C ABI interop, or runtime execution in CI.

## Scope

- Add explicit backend-neutral capability metadata to the target registry.
- Cover at least: codegen, default linker flavor, hosted runtime requirement, sysroot policy, CRT policy, C ABI availability, and freestanding support.
- Drive CLI validation/help and `wavec print target-spec --format=json` from the metadata.
- Preserve exact-triple lookup.
- Add registry invariants so impossible combinations fail in tests.
- Do not claim support for targets that are not implemented.

## Completion criteria

- [ ] CLI code no longer infers core capability decisions from scattered triple strings.
- [ ] Every registered target has an explicit capability record.
- [ ] Target-spec JSON exposes the capability state.
- [ ] Existing Linux, Darwin, Windows GNU, and freestanding behavior is unchanged.
- [ ] New target issues can define acceptance in terms of these capabilities.

Start at the target registry and the `wavec print target-spec --format=json` entry point; inventory how CLI validation and help currently derive capability decisions. Review the registry invariants and existing Linux, Darwin, Windows GNU, and freestanding behavior. Done means every registered target exposes explicit capabilities without claiming unsupported targets or changing existing behavior.

Written by the indexing model from the issue text.