dependency check: repurpose for bzlmod (most of current checker is redundant/broken)

## Summary

The `envoy.dependency.check` dependency checker was designed around Envoy's WORKSPACE-era dependency architecture, where every dependency was declared in `repository_locations.bzl` as an `http_archive` with colocated metadata (`version`, `urls`, `release_date`, `sha256`, `use_category`, `cpe`, ...).

As Envoy migrates to bzlmod (`MODULE.bazel` + BCR), most of this checker is either **redundant** or **silently broken**, and needs to be repurposed rather than patched.

## Why it breaks under bzlmod

The checker derives a dependency's upstream release identity by **scraping the GitHub archive URL** (`github_url` → `url_components` → `github_version`). This only works for deps that carry a GitHub `urls` entry in the expected archive/release shape.

Under bzlmod, registry (BCR) modules have **no `urls` / no GitHub archive URL**. For those deps:

- `github_url` resolves to `""`,
- `url_components` raises `NotGithubDependency`,
- the dep is silently dropped from `github_dependencies`.

The practical effect is that checks don't error — they **go green while verifying nothing** for exactly the deps that moved to the registry.

Separately, the upfront `_validate_dependency_metadata` gate still requires a hex `sha256` key per dep. Under bzlmod the archive hash is no longer part of dep metadata (it lives as SRI `integrity`, and registry modules carry no hash at all), so this gate now fails for ~all deps — despite `sha256` / `release_sha` being unused by any of the actual checks.

## Assessment of the three current checks

- **`release_dates`** — *still wanted, but currently can't cover bzlmod deps.* We still keep dates in `deps.yaml` and they should be correct. But as implemented this check resolves the release via URL scraping, so it can only validate deps that still carry a GitHub URL (remaining raw-archive / git-SHA pins). For registry-backed deps it validates nothing. To be useful it must resolve upstream release identity from the module/registry mapping, not scraped URLs.
- **`releases`** — *largely redundant here.* "Is there a newer upstream release" belongs on the registry, where newness tracking (and issues) can be handled directly.
- **`release_issues`** — *only as useful as `releases`.* It's the issue-tracker bookkeeping layer on top of `releases`; redundant to the same extent.

## Capabilities we want to keep / build

1. **Registry-side upstream release checking** — the registry (BCR) can check for, and file/manage issues for, actual new upstream releases of a module.
2. **Registry-update checking from Envoy (or other consumers)** — a check that surfaces when the registry entry for a dependency has been updated and newer versions are available for a consumer to bump to. Possibly one issue per dep, opened when the registry advertises a new version.
3. **Release-date checking** — retained, but re-plumbed to the bzlmod deps model so it can actually validate `deps.yaml` dates for registry-backed deps (resolving upstream release identity via module metadata rather than URL scraping).

## Notes

- `sha256` / `release_sha` / `release_sha_mismatch` / `display_sha` are unused by any check; they are WORKSPACE-era `http_archive` plumbing and can be dropped when the checker is repurposed.
- This is a design/refactor issue, not a spot fix — the checker needs to be reoriented around how the bzlmod pipeline represents each dependency (whether/how `url` / `version` / `release_date` are present per dep) before deciding which parts to re-plumb vs. replace.

Related Envoy work: bzlmod migration (envoyproxy/envoy#42890).