Expose wee8 prebuilt as a registry module (replacing the toolshed repo rule)

## Background

`envoyproxy/toolshed` now builds and publishes prebuilt V8/wee8 static archives:

- Producer: [toolshed#5019](https://github.com/envoyproxy/toolshed/pull/5019) adds `bazel/v8/wee8_package.bzl` + the `package-v8` CI job, producing `v8-wee8--linux-{x86_64,aarch64}.tar.xz` attached to the `bins-v{version}` release.
- Consumer (interim): a follow-up PR adds a `wee8_prebuilt` repository rule in toolshed plus `wee8_sha256` entries in `bazel/versions.bzl`, wired up via the `update-versions.yml` sed plumbing.

The toolshed-side consumer was chosen deliberately as a **stopgap**, because Envoy is still on WORKSPACE and a `bazel_dep` is not usable there yet.

## Why this should move to the registry

- Taking a `bazel_dep` on **toolshed** just to obtain one static archive is a heavy and badly-layered dependency — it makes toolshed a distribution channel for a third-party library rather than a toolchain/utility repo.
- It couples the wee8 version to toolshed's release cadence: bumping wee8 requires a bins release *and* a toolshed release.
- The version + SHA currently live in `bazel/versions.bzl`, updated by a bespoke `sed` block in `update-versions.yml`. That pattern is already copy-pasted five times (sanitizers, sysroots, glint, llvm-minimal, and now wee8); the registry's `source.json` already has tooling, presubmit and a review flow for exactly this.

## Proposal

Add a registry module (e.g. `wee8-prebuilt@.envoy`) as a sibling to the existing `v8@14.6.202.10.envoy` module, which downloads the prebuilt tarball from the toolshed `bins-v{version}` release instead of building V8 from source.

**Key requirement: the module MUST expose the same label surface as the from-source `v8` module** — i.e. `@v8//:wee8` with an equivalent `CcInfo`. If the label surfaces match, then:

- Swapping source ↔ prebuilt is a one-line `bazel_dep` / `single_version_override` change in the consumer, with no code change.
- The choice becomes a *consumer* decision made at module resolution time, rather than being baked into which repo rule you happen to load.
- The toolshed `wee8_prebuilt` repo rule can be **deleted outright**, rather than left as a second parallel code path.

If the label surfaces diverge, both paths have to be maintained indefinitely — that is the failure mode to avoid.

## Tarball layout

As produced by `wee8_package.bzl`:

```
lib/libwee8.a fat static archive (V8 + fast_float/simdutf/highway/fp16)
include/ V8 public C++ API headers + wasm-api headers
third_party/ canonical third_party/wasm-api/ paths
src/ internal V8 headers exported via CcInfo (e.g. src/wasm/c-api.h)
```

Note abseil and icu are deliberately **excluded** from the fat archive (`exclude_lib_prefixes = ["abseil-cpp+", "icu+"]`) — they are expected to be provided by the consumer, so the module needs to declare those as deps rather than vendoring them.

## Prerequisites / sequencing

1. Land toolshed#5019 (producer) and the toolshed consumer follow-up.
2. **Validate that the fat archive actually links against Envoy.** This is the open risk — `wee8_package.bzl` runs `ar` under `no-remote-exec` because it must match the target toolchain, which is exactly the sort of constraint that yields an archive that packages cleanly but links badly. Don't commit to the distribution shape until something has consumed it end to end.
3. Then add the registry module and retire the toolshed repo rule + `versions.bzl` / `update-versions.yml` wee8 plumbing.

## Open question: macOS

The current producer is Linux-only (`linux-x86_64`, `linux-aarch64`). Whether a `macos-arm64` variant is needed depends on whether wee8 is in Envoy's standard macOS build — worth resolving before finalising the module's platform matrix. See discussion on the toolshed side.

Start by reading toolshed#5019 and bazel/v8/wee8_package.bzl, then inspect the existing v8@14.6.202.10.envoy module and its label surface. Validate the produced fat archive by consuming it in Envoy and confirming it links end to end. Done means a registry module exposes @v8//:wee8 with equivalent CcInfo, declares required dependencies, and the toolshed repo rule and wee8 version-update plumbing are retired.

Written by the indexing model from the issue text.