The standard way to get wifi firmware onto a from-scratch Linux system is to clone linux-firmware, the upstream repository that bundles binary blobs for essentially every wireless chip Linux supports. It's several gigabytes. This build needed exactly one chip's worth of files, and already had a machine sitting right next to it that had already solved the problem of knowing which ones.
What the driver actually asked for
The kernel build (documented separately) carried forward the ath12k driver specifically because this machine's own currently-running Ubuntu install already has that exact driver bound to this exact wifi chip, successfully, confirmed via lspci -k and lsmod. That host system has also already solved the firmware question — its own /lib/firmware directory contains exactly the files ath12k needs for this chip: the WCN7850 firmware images plus the regulatory database and its signature file. Nobody had to determine which firmware files this chip needs by reading driver source or guessing from a naming scheme; the running system had already answered that question by working.
What building the whole repository would have cost
Cloning linux-firmware in full pulls down every vendor's firmware for every wireless, graphics, and peripheral chip the kernel supports — a repository sized in gigabytes, the overwhelming majority of it for hardware this specific machine doesn't have and never will. Building or even just fetching all of it to extract the handful of files one chip actually needs is real, avoidable cost for information the machine already had sitting locally. BLFS itself doesn't treat linux-firmware as a normal versioned package for the same underlying reason — there's no single meaningful "version" of a blob collection nobody installs in full, only the specific files a specific piece of hardware needs.
Copying instead of building
The fix was to treat the host's own /lib/firmware as the source of truth and copy directly from it: the ath12k/WCN7850/ directory and the regulatory database files, nothing else. No compilation step, no package version to track, no upstream release to pin — a plain file copy from a system already proven to work, onto a system built specifically to run the same hardware. The step isn't tracked with a version-stamped build the way every compiled package in this project is; it's a bare completion marker, because there's nothing to version. The files either match what this chip needs or they don't, and the host machine had already demonstrated that they do.
Knowing what you need instead of what the instructions assume
The generic instruction — "install linux-firmware" — is correct in the sense that it would eventually produce a working system, at the cost of downloading and storing several gigabytes of firmware for chips that will never exist on this machine. The actual requirement was narrower and already answered: one chip, one directory of files, verified against a real, currently-functioning instance of exactly the hardware in question. Reaching for the full generic solution here would have worked, eventually, and cost real time and disk space to get to the same three or four files a five-second copy already had sitting one filesystem away.