Update 'warg' references to OCI and 'wkg' references

Author: lukewagner

design/mvp/Explainer.md

@@ -2648,7 +2648,8 @@ and `b` to a component `c` and `/d/e/f` traverses the exports of `c` (where `d`
 and `e` must be component exports but `f` can be anything). Given this abstract
 definition, a number of concrete data sources can be interpreted by developer
 tooling as "registries":
-* a live registry (perhaps accessed via [`warg`])
+* a live registry (perhaps accessed via [`wkg`] and the [WebAssembly OCI
+  Artifact Layout])
 * a local filesystem directory (perhaps containing vendored dependencies)
 * a fixed set of host-provided functionality (see also the [built-in modules] proposal)
 * a programmatically-created tree data structure (such as the `importObject`
@@ -3321,9 +3322,10 @@ For some use-case-focused, worked examples, see:
 
 [Component Model Documentation]: https://component-model.bytecodealliance.org
 [`wizer`]: https://github.com/bytecodealliance/wizer
-[`warg`]: https://warg.io
+[`wkg`]: https://github.com/bytecodealliance/wasm-pkg-tools
 [SemVerRange]: https://semver.npmjs.com/
 [OCI Registry]: https://github.com/opencontainers/distribution-spec
+[WebAssembly OCI Artifact Layout]: https://tag-runtime.cncf.io/wgs/wasm/deliverables/wasm-oci-artifact/
 
 [Scoping and Layering]: https://docs.google.com/presentation/d/1PSC3Q5oFsJEaYyV5lNJvVgh-SNxhySWUqZ6puyojMi8
 

design/mvp/Linking.md

@@ -90,13 +90,13 @@ either store child modules or components **inline** or to **import** them from
 an external registry. This registry toolchain integration is still in progress,
 but by reusing common support libraries such as [`wasm-pkg-tools`], higher-level
 tooling can uniformly interact with multiple kinds of storage backends such as
-local directories, [OCI Wasm Artifacts] stored in standard [OCI Registries] and
-[warg registries]. Of note, even when modules or components are stored inline
-by earlier stages of the build pipeline, when creating an OCI Wasm Artifact, a
-toolchain can (hypothetically, existing tools don't do this yet) enable
-deduplication by content-hash of common modules or components by placing them
-in separate OCI [`layers`] which are imported via [`hashname`] by the root
-component stored in the first layer of the OCI Wasm Artifact.
+local directories, [OCI Wasm Artifacts] stored in standard [OCI Registries]. Of
+note, even when modules or components are stored inline by earlier stages of the
+build pipeline, when creating an OCI Wasm Artifact, a toolchain can
+(hypothetically, existing tools don't do this yet) enable deduplication by
+content-hash of common modules or components by placing them in separate OCI
+[`layers`] which are imported via [`hashname`] by the root component stored in
+the first layer of the OCI Wasm Artifact.
 
 
 ## Fully-runtime dynamic linking