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

[jeremi]

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.