## uses_functions

Cuando un .cpp llama a otra funcion del registry, el `.md` del CONSUMIDOR
debe anadir la dependencia a `uses_functions`. El indexer NO lo deduce
automaticamente para C++ (parser no trivial).

Como auditar (funciones huerfanas):
  sqlite3 registry.db "SELECT id FROM functions WHERE lang='cpp' AND uses_functions='[]';"

Como auditar (drift entre `CMakeLists.txt` y `app.md`):
- Cruzar los `${CMAKE_SOURCE_DIR}/functions/<dom>/<name>.cpp` listados en el
  `CMakeLists.txt` con el `uses_functions` del `app.md`. Cada `.cpp` linkado
  debe aparecer como `<name>_cpp_<dom>` en el `.md`. Excepciones: ver mas abajo.

Convencion:
- **Framework code** (`cpp/framework/app_base.cpp`) — no esta indexado.
- **Funciones bundled en `fn_framework`** — son funciones del registry cuyo
  `.cpp` se compila dentro del static lib `fn_framework` (lista en
  `cpp/CMakeLists.txt`, target `add_library(fn_framework STATIC ...)`):
  `tokens`, `icon_font`, `app_settings`, `app_about`, `fps_overlay`,
  `panel_menu`, `app_menubar`, `layouts_menu`, `logger`, `log_window`,
  `gl_loader`, `layout_storage`, `selectable_text`. Las apps las usan
  transitivamente (incluyen `core/logger.h`, llaman `fn_log::log_info`),
  pero NO listan estos `.cpp` en su `CMakeLists.txt` (multiple-definition)
  ni los declaran en `uses_functions` del `app.md`. Excepcion: si una app
  toca una API que no este en fn_framework (raro), declara la dep.
- **TU adicional de un parent function** (ej. `graph_labels_select.cpp` que
  va con `graph_labels.cpp`) — desde 2026-05-04 se registra como entrada
  propia con su `.md` (ver ADR 0003). El parent declara la nueva entrada
  en su `uses_functions`. Las apps que enlazan ambos `.cpp` listan ambas
  IDs en `uses_functions` del `app.md`.
- **Apps** (`apps/`, `cpp/apps/`, `projects/*/apps/`) son leaves del grafo:
  declaran `uses_functions` en `app.md` pero ninguna funcion del registry
  las cita.
- DEMO_ONLY en `primitives_gallery` se etiqueta `notes: scaffolding/demo`.