"""审批流程台账 (approval-flow registry).

Every approval flow the company runs lives in Feishu 审批 — dozens of
them, across HR, finance, legal, IT and recruiting. Two questions had
nowhere to be answered:

1. **"How many approvals do we actually have?"** The list existed only
   inside the Feishu approval admin console, paginated and visible to
   its administrators.
2. **"Who is responsible for this flow?"** Partly in Feishu, as the
   definition's 流程管理员 (``approval_admin_ids``) — but that field is
   omitted from the response unless the request asks for it with
   ``?with_admin_id=true``. This module read the definition without the
   param, saw no key, and wrote 「飞书没有负责人字段」 into its own
   docstrings; 32 of 49 flows published 「还没人认领」 while the Feishu
   console showed a name. Corrected 2026-08-27: the sweep now asks for
   the admins, publishes them as 飞书流程管理员, and adopts a lone
   still-employed admin as the flow's candidate owner.

Feishu still does not answer it *completely* — a definition can name
seven admins, and a set of seven is not an owner — so the register is
built here, published to everyone, and kept honest by a half-yearly
confirmation from the named owners themselves.

**Deliberately NOT** a mirror of Feishu 审批. It holds the definition's
identity (code, name, group), its lifecycle status, and accountability.
It does not store approval nodes, form structure, or anything from an
instance — those carry HR, finance and legal payloads that Feishu
already owns and protects, and a registry that copied them would be a
second place to leak them from.

Related: ``app.approval`` is the *transactional* integration (Helix's
own 18 flows: submitting instances, receiving callbacks, mirroring
status). This domain is the *inventory* of every flow, including the
ones Helix has nothing to do with. They share the Feishu client and
nothing else.
"""