Move bazel-registry out of toolshed into envoyproxy/bazel-registry

## Background

`bazel-registry/` currently lives in this repo (issue was moved from toolshed). Leveraging toolshed's out-of-the-box CI has worked well as a bootstrap, but the registry's maintenance model is fundamentally different from toolshed's — in terms of the likely contribution profile (frequent, narrow, dependency-bump style changes from a wider set of people), and in terms of governance.

The registry was originally intended to live in `envoyproxy/bazel-registry`. This issue tracks moving it back there.

Moving it out also unlocks two things that are awkward to do here:

- **Selective CI** — today every change fans out over the whole module set. In a dedicated repo we can run only the targeted bits needed for the modules/versions actually touched, while *also* running a more extended BCR-like suite (on Envoy's RBE, as toolshed does).
- **Publishing conventions** — the registry needs rules that don't apply to toolshed, most notably that modules are immutable **between versions**.

## Current state

- `bazel-registry/modules/**` — 80+ modules in standard BCR layout (`metadata.json`, `/source.json`)
- `.github/workflows/bazel-registry.yml` — path-filtered trigger, discovers modules via `find`, matrixes over *all* modules
- `.github/workflows/_bazel_registry.yml` — per-module reusable workflow; matrixes over versions filtered to `endswith(".envoy")`, runs integrity check per source URL
- `.github/workflows/registry_integrity.sh`

CI today is integrity-only, and fans out over the entire registry rather than the changed subset.

## Scope

### 1. Repo and content move

- Create `envoyproxy/bazel-registry` (does not currently exist)
- Move content with history preserved (`git subtree split -P bazel-registry`), not a flat copy
- Decide registry root layout — `modules/` at repo root (canonical, plus `bazel_registry.json`) vs. retaining the `bazel-registry/` prefix
- Deprecation stub / pointer left in toolshed
- Repoint consumers (`--registry=`) only once the new repo is populated and green

### 2. CI tier 1 — targeted, changed-modules-only

Port the existing integrity CI, but scoped:

- Diff `origin/main...HEAD` for `modules///**` and emit a `{module, version}` matrix
- Continue consuming the toolshed actions (`should-run`, `bson`, `jq`) as pinned refs — dependency direction stays healthy
- Drop the `.envoy`-suffix version filter; in a dedicated registry all versions are in scope, but only *changed* ones run

### 3. CI tier 2 — extended, BCR-style verification on RBE

- Per changed module version: fetch source, apply patches, build the module against a scratch workspace that depends on it (BCR `presubmit.yml` style)
- Run on Envoy's RBE, mirroring toolshed's existing RBE plumbing, rather than fat GH runners
- Gated so metadata-only edits skip it

### 4. Publishing conventions — immutability enforcement

Modules are immutable **between versions**. CI must enforce this:

- For each `modules///` touched in a PR, determine whether `` has already been released
- **Released** is defined by GitHub releases on `envoyproxy/bazel-registry` — authoritative for now
- If released → any modification (`source.json`, patches, `MODULE.bazel`, overlay files) is a hard failure, with a message directing the contributor to cut a new version instead
- If the version directory is added in the PR → allowed
- Companion checks:
- `metadata.json` `versions` must be append-only
- version directories may never be deleted
- `source.json` integrity hashes must be `sha256-` SRI and must match the fetched artifact

### 5. Governance

- Separate `CODEOWNERS` / OWNERS from toolshed
- Lower-friction review path for routine bumps, backed by stronger mechanical enforcement in CI

## Open questions

- Registry root layout — `modules/` at repo root, or keep the `bazel-registry/` prefix?
- Staging: single PR for the subtree move plus workflows, or prove the immutability check as a standalone PR against toolshed first?

Start by reading the current bazel-registry/ tree and .github/workflows/bazel-registry.yml, .github/workflows/_bazel_registry.yml, and .github/workflows/registry_integrity.sh. Review the proposed git subtree split and resolve the open root-layout and staging questions before making changes. Done means envoyproxy/bazel-registry is populated with history, consumers are repointed after CI is green, and targeted, extended, and immutability checks are in place.

Written by the indexing model from the issue text.