now explain how the term "enrich" applies to a CVE
It's basically parsing the CVE and adding more details. A CVE is basically like a bug report, often you'll get basic information. Enrichment is the process of fleshing out more details that were omitted because they weren't required, but adding information to make the bug more easily tracked for statistical and tracking information.
Enrichment by NIST is basically looking over the bugs and assigning the vulnerability IDs to them - there's a catalog of vulnerability types and it basically classifies them using a shorthand code. Things like is it remotely exploitable, authentication bypass, buffer overflow, potential code execution, SQL injection, root escalation, etc., A collection of these often makes up the CVE score - which generally maxes out at 9.8 unless there's something extra that warrants it being a full 10 (9.8 being remotely accessible, no authentication required, code execution, root escalation - like basically sending a specially crafted packet to it will get you to arbitrary code execution as root.
Basically a CVE is often just a basic bug report with version , the issue and a few other details when filed. Details may be hidden temporarily if there's no fix out, and enrichment makes the data more useful by adding metadata to flesh it out more. So if you search for vulnerabilities that were remote code execution, you'd find the bugs that involved it.
But this is a manual process and NIST is stopping doing it automatically (thanks budget cuts) for all but the worst bugs that end up on the KEV, or CISA lists.
I think NIST only does the ones that aren't on any CVE handlers - big projects - think companies like Microsoft, or Linux, handle CVEs themselves - they are allocated a block of identifiers and they're responsible for publishing them. They would enrich the reports themselves before releasing it. If there's no CVE agency handling the program or project involved, then it's handled by the general one (like curl was until it got hit with a 9.8 it couldn't get rid of or reclassify - all because a 32-bit int could overflow and hit a website more often than specified - basically it was setting a timeout and if it expired, curl would retry the connection. You could overflow it so instead of waiting nearly 60 years, you'd retry more often than that, leading to a DoS). Curl became their own authoritiy after that.