`Architecture = auto` expansion is invisible to third-party libalpm consumers (PackageKit, pyalpm, pacutils)

OK, I admit I had a lot of help from Claude on this one too, but here we go...

## Summary

CachyOS's pacman fork adds a libalpm API, `alpm_option_get_physical_architectures()`, and changes pacman's `Architecture = auto` handling to use it, so `auto` expands to `x86_64 x86_64_v2 x86_64_v3 x86_64_v4` on a capable CPU. That is sensible and this is not a defect report.

The gap is that every *other* libalpm consumer that parses `pacman.conf` resolves `auto` the way upstream pacman does, with a single `uname()` call. They get `[x86_64]` only, and every `x86_64_v3`/`x86_64_v4` package then fails `check_arch()` with `ALPM_ERR_PKG_INVALID_ARCH`. Nothing in the config file or the libalpm API signals that this distribution expects the expanded list, so tool authors cannot discover the divergence.

CachyOS already handles this for one consumer: `libpamac-aur` carries `0001-add-arches-from-pacman-func-call.patch`, which teaches libpamac to call the new API. The same fix is missing for the other consumers in the repos, and there is no documentation a third-party author could find.

## Where the expansion lives

- `CachyOS/pacman` commit `b364651ee0717cdb585ad4dd0be0be4f842f4201`, "add support for x86_64_v{2,3,4} autodetection" (Vladislav Nepogodin, 2022-12-02). Branch `release/7.1.x`, not `master`. Files: `lib/libalpm/cpu_capabilities.c` (new), `lib/libalpm/alpm.h` (adds the export), `src/pacman/conf.c` (`config_add_architecture()` calls it for `auto`).
- Shipped via `CachyOS-PKGBUILDS/pacman/PKGBUILD`, currently pinned to `4056cd687f6379e61e7decb9b66e9b57cb3949a9` (pacman `7.1.0.r9.g54d9411-4`).
- `libpamac-aur/0001-add-arches-from-pacman-func-call.patch` (2022-12-18) is the existing per-consumer fix.

## What consumers actually get on this machine

CachyOS, `pacman 7.1.0.r9.g54d9411-4`, `libalpm.so.16.0.1`, `Architecture = auto`, CPU supports v4.

| Consumer | How it resolves `auto` | Architectures passed to libalpm | Result on a v4 package |
|---|---|---|---|
| CachyOS pacman | `alpm_option_get_physical_architectures()` | `x86_64 x86_64_v2 x86_64_v3 x86_64_v4` | OK |
| libpamac (CachyOS-patched) | same, via downstream patch | same | OK (not tested here, by construction) |
| PackageKit `pk-alpm-config.c` | `uname()` | `x86_64` | `ALPM_ERR_PKG_INVALID_ARCH`, then segfault (PackageKit/PackageKit#1009) |
| pyalpm / pycman `config.py` | `os.uname()` | `x86_64` | `ALPM_ERR_PKG_INVALID_ARCH`, then segfault in pyalpm's error path |
| pacutils (`pacconf`, `pacinstall`) | `uname()` | `x86_64` | `error: invalid architecture (glibc-…-x86_64_v4)` |

Note that pyalpm and pacutils are both built and shipped by CachyOS (`pyalpm 0.11.1-1.1`, `pacutils 0.15.0-3`, packager `CachyOS `) without an equivalent of the libpamac patch.

Reproduction, using a throwaway dbpath so nothing touches the live system:

```
$ mkdir -p /tmp/db/{local,sync}; cp /var/lib/pacman/sync/*.db /tmp/db/sync/; echo 9 > /tmp/db/local/ALPM_DB_VERSION

$ pacman-conf Architecture # CachyOS pacman
x86_64
x86_64_v2
x86_64_v3
x86_64_v4

$ pacconf Architecture # pacutils, same pacman.conf
x86_64

$ pacman -S --dbpath /tmp/db --print glibc | tail -1
file:///var/cache/pacman/pkg/glibc-2.44+r24+g16be1518495f-1-x86_64_v4.pkg.tar.zst

$ pacinstall --dbpath=/tmp/db --print-only glibc
error: invalid architecture (glibc-2.44+r24+g16be1518495f-1-x86_64_v4)
```

pyalpm, same dbpath:

```python
import pyalpm, pycman.config
h = pycman.config.init_with_config('/etc/pacman.conf') # dbpath overridden to /tmp/db
print(h.arch) # ['x86_64']
pkg = h.get_syncdbs()[0].get_pkg('glibc') # arch x86_64_v4
t = h.init_transaction(); t.add_pkg(pkg); t.prepare() # -> SIGSEGV
```

The pyalpm segfault is a separate pyalpm bug (its prepare error path treats the `ALPM_ERR_PKG_INVALID_ARCH` data list as `alpm_depmissing_t*`, mirroring the PackageKit one) and reproduces on stock Arch with any mismatched `Architecture`. It is mentioned here only because CachyOS's expansion is what makes it fire on every transaction for CachyOS users of pyalpm-based tools.

## Suggestions

Any of these would close the gap. In rough order of preference:

1. Make the expansion happen where every consumer sees it. If libalpm expanded `auto` inside `alpm_option_set_architectures()` / `alpm_option_add_architecture()`, every frontend would get it for free with no code change. That is a behavioural change to a public API, so it may not be acceptable, but it is the only option that fixes consumers CachyOS does not package.
2. Carry the equivalent of the libpamac patch for the other libalpm consumers CachyOS ships: `pyalpm` (pycman `config.py`), `pacutils` (`lib/pacutils/config.c`). Both are single-function changes.
3. Document the API and the expectation somewhere a tool author would find it: a note in the shipped `pacman.conf` next to `Architecture = auto`, a paragraph on the "Optimized Repositories" wiki page, or a section in the `CachyOS/pacman` README. Even "if you link libalpm and parse `Architecture = auto`, call `alpm_option_get_physical_architectures()` when it is available" would be enough.

Happy to send PRs for 2 or 3 if that is the preferred route.

## Related

- PackageKit/PackageKit#1009 (crash) and #1010 (fix). The issue's original claim that PackageKit's `auto` handling was itself a bug was retracted; PackageKit does exactly what upstream pacman does.

Start with lib/libalpm/cpu_capabilities.c, lib/libalpm/alpm.h, and src/pacman/conf.c to understand the exported architecture handling, then compare the parsing paths in pycman config.py and lib/pacutils/config.c. Review the existing libpamac-aur patch and choose an agreed fix or documentation route; done means affected consumers no longer miss the expanded architectures, or the expectation is documented for tool authors.

Written by the indexing model from the issue text.