chore(deps): move the ingest library pin to v0.3.2 — as far as latest goes today

The pin had sat at v0.3.1 with STATE calling the hold "deliberate" and
recording no reason. Measured: no coord message ever announced v0.4.0 or
v0.5.0a* to this repo, so the hold was drift wearing a decision's clothes.

v0.3.2 is a pure fix (frontmatter and index labels emit verbatim; only
source_query is whitespace-collapsed, per ingest-spec §5), keeps
`dependencies = []`, and is green here: 668 passed.

WHY NOT FURTHER, both measured rather than assumed:

1. v0.4.0 introduces a REGRESSION that breaks our §6 removal path.
   Bisected v0.3.2 OK / v0.4.0 RED with a minimal repro: materialize a
   bundle, then re-materialize it with a CHANGED manifest, and the library
   no longer recognises its own stamp —

     MaterializationError: generated filename 'ingest-costs.md' collides
     with an existing file that does not carry the ingest stamp

   The stamp carries the manifest's name+hash (`ingest_manifest: m2@…`), so
   editing a manifest makes every file it previously wrote look curated.
   Re-ingesting the SAME manifest is fine, which is why fixtures miss it.
   It is `tests/test_ingest_loadbearing.py::test_reingest_with_active_
   removal_preserves_promoted_and_curated` that catches it. Reported
   upstream; not ours to fix.

2. Everything past v0.3.1 adds `llm-ingestion-guard>=0.2,<0.3` as a HARD
   runtime dependency (v0.3.1/v0.3.2: `dependencies = []`). That flips two
   documented invariants here — pyproject's "zero runtime deps" comment and
   the STATE marker line the guard repo reads machine-readably ("not a
   runtime dependency today"). An operator decision, not a version bump.

3. v0.5.0a2 is an alpha whose own CHANGELOG scopes it to a named pilot set
   — portfolio-optimiser-claude, the marketplace catalog, claude-code-llm-wiki
   — and says "do not pin this tag outside the pilot set", with the v0.2
   surface free to change without a deprecation cycle. This repo is not a
   pilot. Joining is llm-ingestion-okf's call, requested via coord.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GyAbxJoyypnLLUDcMvnKh8

tests/test_ingest_library_seam.py

@@ -52,7 +52,7 @@ def _project(tmp_path: Path, source: dict[str, Any] | None = None) -> tuple[Path
 
 def test_adapter_stamp_equals_library_stamp(tmp_path: Path) -> None:
     """LOAD-BEARING ANTI-DRIFT: the adapter's ``load_manifest`` restates the §5 stamp formula
-    because the library (v0.3.1) mints the stamp inside ``materialize_bundle`` and exposes no
+    because the library (v0.3.2) mints the stamp inside ``materialize_bundle`` and exposes no
     stamp helper. That is the ONE place the adapter is not purely delegating, so the two
     formulas can drift apart silently — this compares the adapter's value against the stamp the
     library actually writes into ``ingest_manifest`` frontmatter. RED the moment either side

tests/test_ingest_mcp.py

@@ -10,7 +10,7 @@ is STALE and deliberately not followed here.
 **Why the discriminator lives in ``base_url``, not in new manifest fields.** The shared library
 rejects unknown manifest keys fail-fast (``llm_ingestion_okf.manifest._require_keys``): an ``http``
 source admits exactly ``{type, id, base_url}`` plus optional ``credential_ref``. We are a PULL-ONLY
-consumer pinned at ``v0.3.1``, so adding ``server_ref``/``tool`` as fields would require a spec
+consumer pinned at ``v0.3.2``, so adding ``server_ref``/``tool`` as fields would require a spec
 amendment plus a library release. It is not needed: the library's own URL join already composes
 ``base_url`` + ``/`` + ``query``, so ``mcp+stdio://<server_ref>`` + ``<tool>`` reproduces exactly
 the two-part structure the stale plan wanted — with zero schema change. Field names were explicitly