`otherNames` name-class filter is narrower than the comment and docstring claim (`genbank acronym`, `blast name`)

Part of #1733. Found in the review of #1732.

## Problem

`taxonomy_lineages_with_names.sql` reads these NCBI name classes:

```
'genbank common name'
'common name', 'acronym'
'equivalent name', 'synonym'
```

Two documentation strings describe that as broader than it is:

- the model's header comment — "every non-scientific name NCBI knows for the taxon";
- the `search_organisms` docstring in `backend/api/app/services/catalog_data.py` — "common names, acronyms, and prior or alternate scientific names".

`'genbank acronym'` and `'blast name'` are both non-scientific name classes in `names.dmp` and neither is read. #1732's PR body justifies excluding `genbank synonym` (NCBI no longer populates it) but says nothing about these two.

## Why it matters

If `genbank acronym` still has rows, virus acronyms (the class where they mostly live) are silently absent from `otherNames` while the assistant is told they are present — so the model will assert an acronym isn't in the catalog rather than falling back to another lookup.

## What to do

1. Query the built catalog DB — `select name_class, count(*) from taxonomy_names group by 1 order by 2 desc` against `catalog/build/temp/catalog.duckdb`.
2. If `genbank acronym` / `blast name` are unpopulated for the taxa we keep: tighten the two doc strings to say which classes are read, and note the exclusion the way `genbank synonym` is noted.
3. If they are populated: add them to the filter groups (acronym alongside `'acronym'`, blast name likely alongside the common-name group) and regenerate.

Either outcome, the header comment and the `search_organisms` docstring should end up naming the classes rather than claiming "every non-scientific name".