debuginfod.cachyos.org unreachable (Cloudflare 522); no debug symbols obtainable for v3/v4 rebuilds

I had help with Claude/AI on this, but thought it was worth reporting.

`cachyos-settings` ships `/etc/debuginfod/cachyos.urls` pointing at
`https://debuginfod.cachyos.org` (added in #57).

That host has been returning **Cloudflare 522 (origin unreachable)** on every path for at least two day.

So `gdb` / `coredumpctl debug` cannot fetch symbols for any CachyOS-built package.
This may be transient and you may already know; filing in case not.

## Reproducer

```sh
BID=$(readelf -n /usr/lib/libalpm.so.16.0.1 | grep -oP 'Build ID: \K[0-9a-f]+')
curl -sS -o /dev/null -w "buildid: %{http_code}\n" --max-time 25 \
"https://debuginfod.cachyos.org/buildid/$BID/debuginfo"
curl -sS -o /dev/null -w "root: %{http_code}\n" --max-time 25 \
"https://debuginfod.cachyos.org/"
```

Observed 2026-09-09 02:02 UTC:

```
/buildid//debuginfo 522
/buildid//debuginfo 522
/ 522
/metrics 522
```

Earlier on 2026-09-09 (~00:00 UTC) the same paths, plus build-ids for `vlc` and
`libglib-2.0.so.0`, returned 522 across four attempts over about a minute; one
attempt timed out at 20 s with no response.

On 2026-09-08 the same host returned **404** rather than 522 for a `packagekit`
1.3.6-1.1 `x86_64_v4` build-id. So across two days I have seen two different
failure modes, and no debug info was obtainable either way. I don't know which
one is the real story.

## Why it matters

On a v3/v4 install essentially every package is a CachyOS rebuild with its own
build-id, so `debuginfod.archlinux.org` cannot serve them. Even `gdb` itself
(17.2-1.1, `x86_64_v4`) 404s against Arch's server:

```
https://debuginfod.archlinux.org/buildid/d7d7b482e3dd88e085f057732724db17630fadb7/debuginfo -> 404
```

With the CachyOS instance down, `coredumpctl debug` gives `No symbol table info available` for every frame.

The people this hits are exactly the ones trying to file good crash reports (e.g. CachyOS-PKGBUILDS#1534).

First-hand example: debugging a `packagekitd` SIGSEGV on 2026-09-08,
`coredumpctl debug` with the matching binary reinstalled from cache produced no
symbols at all. I had to find the crashing function by disassembling around the
return address in `libpk_backend_alpm.so` and matching it against upstream
source. That worked (PackageKit/PackageKit#1009) but it is not a reasonable
expectation of a bug reporter.

## Asks

1. Is `debuginfod.cachyos.org` expected to be up? If it has been retired, the
`.urls` file should probably go so `gdb` stops waiting on it.
2. When it is up, does its index cover the `x86_64_v3`/`v4` rebuilds, or only a
subset? The 404 on 2026-09-08 makes me unsure.

## Environment

- CachyOS, kernel 7.2.3-1-cachyos, `x86_64_v4` repos (`[cachyos-v4]`, `[cachyos-extra-v4]`, `[cachyos-core-v4]`)
- `cachyos-settings 1:1.4.0-1` (owns `/etc/debuginfod/cachyos.urls`)
- `libelf 0.196-1` (owns `/etc/debuginfod/archlinux.urls`)
- `gdb 17.2-1.1`

Start with /etc/debuginfod/cachyos.urls shipped by cachyos-settings and reproduce the failure using the provided readelf and curl commands against debuginfod.cachyos.org. Check whether the service is expected to be available and whether its index covers x86_64_v3/v4 rebuilds. Done means restoring usable debug-symbol retrieval or confirming that the URL should be removed.

Written by the indexing model from the issue text.