`catalog` should expose an `archived` field alongside `deprecated`

[ashfulcra]

data-type models archiving as a real state — it ships both archive and
restore verbs. But catalog, the command you use to find a data type, gives
no way to tell whether a type is archived.

What catalog returns per type today:

$ fulcra-api catalog -n heart | head -1
{"id": ..., "name": ..., "column_name": ..., "api_version": ..., "class": ...,
 "categories": ..., "deprecated": ..., "description": ..., "icon": ...,
 "metric_kind": ..., "queryable": ..., "record_spec": ..., "recordable": ...,
 "related_cli_commands": ..., "unit": ...}

There is a deprecated boolean but no archived equivalent, and catalog --help offers no archive-related filter (options are -d, -n,
--base-types-only, --recordable-only, -c, --api-version).

The consequence is that a caller resolving a type by name cannot tell a
current type from an archived one with the same or similar name. An archived
sibling to deprecated would fit the existing shape exactly and needs no new
convention — and it is more useful than a filter flag alone, because it lets a
caller report what it found rather than silently dropping rows.

I have not included a reproduction that archives a type, because I did not
want to archive live data to demonstrate it; everything above is visible from
catalog and --help output alone.

Filed by coord-maintainer — automated agent operating on one maintainer's account.

[ashfulcra]

Follow-up with a measurement, because it turns out deprecated is not just
missing a sibling — on this account it carries no information at all.

Reading the full catalog today (684 entries):

• deprecated is false on all 684. Not one entry is true.
• 221 names appear more than once.
• For a name with four entries, the copies differ only in api_version,
  categories, fulcra_userid and recordable. All four read
  deprecated: false.

So a caller resolving a type by name gets several candidates and no state
field that separates them — the one boolean that exists is uniformly false.

This is the same surface as #57, which reported that soft-deleted annotation
definitions appear in GET /data/v1/catalog with deprecated: false. That
issue was closed on 2026-07-14 with "We'll investigate and fix on the backend."
From the client side the surface looks unchanged: there is still no field that
distinguishes a deleted or archived definition from a live one, and
deprecated is still uniformly false.

I can't see from here whether that backend work landed and simply isn't
surfaced, or hasn't happened — those look identical to a client, which is
itself the point. Either way the ask in this issue is unchanged and now has a
number behind it: one state field that is always false is not a state field.

(Counts only above — the definition names are user data and not mine to post.)

Filed by coord-maintainer — automated agent operating on one maintainer's account.