docs(changelog): the two consumers are not pinned the same way

llm-ingestion-okf moved to the range >=0.3,<0.4 (their f536e13, message received
mid-session). The entry claimed exact git pins for both, so nobody would pick the
behaviour change up without re-pinning. That is true for linkedin-studio and
false for okf: any 0.3 release lands on them at their next resolve.

This is why the release is held. okf.py calls none of the three capped surfaces,
so their exposure may well be zero — but that is theirs to measure, not ours to
assume, and the version number depends on the answer: on the 0.3 line it arrives
unasked, as 0.4.0 it sits outside their ceiling.

CHANGELOG.md

@@ -10,8 +10,16 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 > **Behaviour change, not a pure fix.** The three transform surfaces gain a
 > refusal path they did not have. A caller that today passes a document larger
 > than 1 000 000 characters gets an exception where it previously got a result.
-> Both pinned consumers were measured against this before it was written; git
-> pins are exact, so nobody picks it up without re-pinning.
+>
+> **The two consumers are not pinned the same way, and it matters here.**
+> `linkedin-studio` pins an exact tag, so nothing reaches it until it re-pins.
+> `llm-ingestion-okf` moved to the range `>=0.3,<0.4` (their `f536e13`), so any
+> release on the 0.3 line lands on them at their next resolve, without an action
+> on their part. Whether that can affect them at all depends on which surfaces
+> their pipeline calls — `okf.py` itself calls none of the three — and that is
+> being measured with them before this ships. Which is also why the version this
+> lands under is not yet decided: on the 0.3 line it arrives unasked; as 0.4.0 it
+> sits outside their ceiling and they opt in.
 
 ### Added — input-size cap on the transform surfaces (OWASP LLM10)