meal-planning: migrate off the retired `recipe` tag to `type: recipe` / list_documents

[St0nefish]

Problem

The knowledge base is being reorganized (branch reorg/top-level-domains), and
the recipe tag has been retired. Every meal-planning skill that enumerates
recipes by that tag will silently return zero results once the reorg merges.

This is a silent failure, not an error: the search succeeds and returns nothing.

What changed in the KB

1. type: recipe now exists. Per-directory .kb-schema.yaml files landed,
   so food/recipes/.kb-schema.yaml narrows the inherited type enum to exactly
   [recipe]. The recipe tag only ever existed because type was globally
   fixed and rejected recipe — that constraint is gone, and the contracts
   document said so explicitly under "Open".

2. lifestyle/kitchen/ is now food/. Recipes live at food/recipes/,
   the meal plans at food/plans/, and the contracts at
   food/meal-planning-contracts.md.

3. Protein / cuisine / method are no longer tags. They were stored twice —
   as tags and in the planning block — on 21 of 23 recipes. They now live
   only in planning as typed enums, filterable via dot-path. Recipe tags now
   carry only what planning does not express: equipment, dish type, dietary.

4. type: meal-plan replaces type: project for plan documents. The
   meal-plan tag is deliberately retained for now precisely so this
   migration doesn't have to happen under time pressure — but it should also
   move to type eventually.

Affected files

• plugins-claude/meal-planning/skills/meal-plan/SKILL.md:36 — "Enumerate the
  recipe collection by searching for the recipe tag, not ..."
• plugins-claude/meal-planning/skills/add-recipe/SKILL.md:218-219 — "An
  unretrofitted recipe is invisible to search. The recipe tag is what makes
  a recipe enumerable ..."
• plugins-claude/meal-planning/skills/add-recipe/SKILL.md:180-183 — tagging
  guidance that references the tag-vocabulary exception; the exception mechanism
  changed (vocabularies are now per-directory schemas, not a global list with a
  carve-out).
• plugins-claude/meal-planning/skills/whats-for-dinner/SKILL.md,
  grocery-cart/SKILL.md, README.md — reference recipe/plan lookup; audit for
  the same assumption.

Suggested fix

Enumeration should move to list_documents, which is the tool built for
exactly this. search is relevance-ranked and returns chunks, not documents,
with a hard cap and no total — it cannot reliably enumerate a set. This was a
real observed failure: listing 17 recipe-tagged documents returned 15, silently.

// enumerate every recipe, reliably
{ "path_prefix": "food/recipes/" }

// or by the new marker
{ "filters": { "type": "recipe" } }

// the planning block is now typed and queryable — numerics stored numerically
{ "path_prefix": "food/recipes/", "filters": { "planning.prep_minutes": { "lt": 30 } } }
{ "path_prefix": "food/recipes/", "filters": { "planning.protein": "chicken", "planning.effort": "low" } }

list_documents always returns total and has_more, so truncation is never
silent.

Note search's tags filter is match-any (OR), not AND — another reason
tag-based enumeration was fragile. list_documents supports all_of.

Caveat

planning.* fields are filterable via list_documents today, but not via
search's dedicated parameters — deep indexed: true in a .kb-schema.yaml
does not create a Qdrant payload index. Don't plan on narrowing a semantic
search by planning.* until that's wired up server-side.

Dependencies

• md-kb-rag list_documents must be deployed (it is implemented on
  feature-list-documents-tool).
• The KB reorg branch reorg/top-level-domains must be merged. Until it is,
  the current tag-based skills still work — this is not yet urgent, but it
  will break the moment that branch lands.

food/meal-planning-contracts.md has been updated with the new schema and
carries this migration note in its "Open" section.

[St0nefish]

Correction to the "Caveat" section above — that limitation no longer applies.

The caveat said planning.* fields would be filterable via list_documents but
not via search, because deep indexed: true didn't create a Qdrant payload
index. That gap has since been closed in md-kb-rag:
SchemaCache::all_indexed_fields() is now wired into both ingest.rs (feeding
ensure_collection) and server.rs (feeding the advertised facets). 489 tests
passing.

So planning.* fields are filterable from search as well. The remaining
distinction is about query shape rather than availability:

• search — Qdrant keyword indexes, equality matches. Use it to narrow a
  semantic query by a category (planning.protein: chicken).
• list_documents — SQLite with a dedicated numeric column, so range
  queries are real ({"planning.prep_minutes": {"lt": 30}}), plus total /
  has_more for exhaustive enumeration.

Enumeration should still move to list_documents — that part of the issue
stands, and is the actual work here.

Also worth noting for whoever picks this up: domain is now derived from the
top-level folder server-side (with_derived_domain) and overrides any
frontmatter domain: key, so domain: food filtering works without the KB
carrying the field at all.