Decide whether the registry-language-core / -wasm extraction lands or is dropped

An in-progress refactor extracts the IO-free analysis layer out of
`registry-language-server` into a reusable `registry-language-core`, plus a
`registry-language-core-wasm` wrapper that targets `wasm32-unknown-unknown`.
It has never landed, and it is now rotting. This issue is to decide whether it
lands or is dropped, rather than to leave it half-done.

## What the work is

It lives on the WIP branch `wip/language-core-wasm-extraction`, tip
`a344a030a` ("chore(language-server): snapshot in-progress language-core
extraction"). The branch is local only; it has not been pushed.

Measured against its merge base (`eb2089153`, `v0.20.1-2`), the real diff is
**+1312 / -2181 across 31 files** — a deduplication, not new surface:

- adds `crates/registry-language-core/`, carrying the evidence diagnostics,
index, layout, openapi, refs and yaml logic
- adds `crates/registry-language-core/tests/no_io.rs`, which enforces that the
core performs no IO
- adds `crates/registry-language-core-wasm/`, a thin `wasm-bindgen` JSON
boundary whose entire public API is `analyze_json(request: &str) -> String`,
`crate-type = ["cdylib", "rlib"]`, `publish = false`
- rewires `registry-language-server` onto the core: `refs.rs` drops ~1289
lines and `yaml.rs` ~667, replaced by `registry-language-core.workspace = true`

## Why it needs a decision now

The branch is **2 commits ahead of main and 120 behind**, forked on 2026-08-12.
Every release widens that gap, and the two files it guts in
`registry-language-server` are files main keeps changing. The rebase cost is
only going up, and at some point the cheaper answer is to throw it away and
redo it.

Neither new crate is in the `[workspace] members` list on main, so nothing on
main builds or tests them today. The extraction is invisible to CI.

## The motivation

Browser-based tooling wants the same diagnostics and completions the language
server computes, without running a language server process. That needs the
analysis layer to be IO-free and compiled to wasm, which is exactly what the
branch does. Downstream consumers are currently reduced to vendoring a
prebuilt wasm artifact with no supported upstream to pin against.

## The decision

1. **Does the extraction land?** If yes, it wants a rebase onto main and the
two crates added to the workspace members so CI covers them.
2. **If it lands, is `registry-language-core-wasm` a released artifact or an
internal crate?** This is the part that actually matters downstream. A
consumer that wants reproducible provenance needs the `.js` / `_bg.wasm`
pair published per release with digests, the way the `evidence` and
`evidencectl` binaries already are. Today the crate is `publish = false`
and no release publishes a wasm asset, so a consumer can only vendor bytes
and record a source revision by hand.
3. **Is `analyze_json(request: &str) -> String` the committed boundary?** A
single JSON-in/JSON-out entry point is cheap to keep stable across
releases, but only if that is a deliberate contract rather than a
convenience of the snapshot. If it is published, it needs a schema and a
compatibility intent.

If the answer to (1) is no, say so and the branch gets deleted, so nobody
rebuilds this from scratch a third time.

Start by inspecting the WIP branch wip/language-core-wasm-extraction at a344a030a against main, especially the new registry-language-core and registry-language-core-wasm crates, registry-language-server refs.rs and yaml.rs, and tests/no_io.rs. Review the workspace members, CI, release assets, and the proposed analyze_json boundary. Done means documenting a decision to rebase and integrate the extraction with its publication contract, or deleting the branch if it will be dropped.

Written by the indexing model from the issue text.