v0.4.29 — fases 4 y 5: version vigente, verificacion, Persona e iniciativa con scope

Las dos fases del rediseño del vault de cliente, juntas en una etiqueta. Todo opt-in por vault: sin las claves nuevas en .okf.config.yaml el comportamiento es el de v0.4.28.

Fase 4 (#39) — la verdad tiene fecha, quien decide es una nota y una nota reemplazada señala su vigente:

• resolves: <Tipo> en types.fields: decidida_por y responsable resuelven a una nota Persona en vez de a texto libre.
• verificado_el / revisar_el con plazo por tipo (types.review.days) o por prefijo de ruta (paths, que gana); stale suma la señal 8 y review separa kind: cyber de kind: verificacion.
• traverse y search saltan a la versión vigente por defecto (--all-versions recorre la cadena).
• health deja de dar 7/8 en un vault cuyos tipos exigen campos.

Fase 5 (#40) — la iniciativa como campo y el alcance por campo:

• types.fields.common y campos con lista, para exigir iniciativa en toda nota salvo la capa de registro y las tareas.
• --scope campo=valor: la frontera de una instancia MCP puede ser un campo del frontmatter. Fail-closed, y un scope mal formado aborta en vez de degradar.

Tests: 523 (485 en v0.4.28), verificados también en un entorno limpio tipo CI. Verificación: suite en worktree y entorno limpio, baseline RED, mediciones reproducidas sobre un clon fresco del vault de cliente, y el efecto sobre OKF-Vault (6 notas ocultas en search, 2 avisos nuevos, health 9/9).