chore(release): prepare 1.1.0 — version sync, changelog, front-page limitations

Version 1.1.0 in pyproject, the package, uv.lock and every README install
line; the "current tag" entry moves to v1.1.0 and v1.0.0 becomes history.
The CHANGELOG states what a user notices: BM25 ranking on passages and
titles, sub-questions in one call, a map per bundle, a weak-coverage
signal, one generic skill plus the server as the standard way in over a
folder, --gate in okf project, and okf-consumption/2 as BREAKING for a
reader of withheld. Known limitations gain the vocabulary route through
the map, the retrieval gate's red rows as they stand under BM25, the
answer smoke test (no corpus content, no counts) and unmeasured speed.

eval/svar/ is ignored the way eval/soek's sets are: answers about a
consumer's corpus are inputs, never committed. No tag, no push.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -10,7 +10,7 @@ types](#supported-file-types) lists each one with the evidence behind it.
 Python 3.10+ and [uv](https://docs.astral.sh/uv/). One line:
 
 ```sh
-uv tool install "llm-ingestion-okf[extract] @ git+https://git.fromaitochitta.com/open/llm-ingestion-okf.git@v1.0.0"
+uv tool install "llm-ingestion-okf[extract] @ git+https://git.fromaitochitta.com/open/llm-ingestion-okf.git@v1.1.0"
 ```
 
 ## Use it
@@ -85,14 +85,35 @@ here was measured; none of it is a plan.
 - **Three of this repository's own gates are RED, and each red row is a stated
   finding rather than a bug to be surprised by.** The retrieval gate is red on
   rows 5, 7 and 8, the MCP gate on row 2, and the content accounting's judge
-  on rows 2, 3 and 6. For a user that means: retrieval quality is measured but
-  not yet green on a held-out set (rows 5, 8), three mechanical mutants of the
-  ranking survive with 0 ranks and 0 deliveries moved (row 7), MCP anchors and concept ids are different
+  on rows 2, 3 and 6. For a user that means: no ranking change has yet been
+  registered against a held-out set (row 5), the real-corpus row is NOT RUN
+  without its private sets and so is red rather than green by omission
+  (row 8), three mechanical mutants of the BM25 ranking survive with 0 ranks
+  moved — the passage body, the title field weight and the fusion constant —
+  so the gate cannot yet tell those parts from their absence (row 7), MCP anchors and concept ids are different
   vocabularies so `okf_fetch` cannot be addressed with a set's anchor (row 2),
   and the accounting still reports real losses on the reference corpus (rows 2,
   3, 6). The rows and their numbers are under [Judge the
   retrieval](#judge-the-retrieval-python3-toolsokf_retrieval_gatepy) and
   [Serve a bundle over MCP](#serve-a-bundle-over-mcp-okf-mcp).
+- **A question worded differently from the bundle finds it through the map.**
+  The ranking is lexical: a question has to share words with the passages it
+  should reach. A question in another language, or in a user's words rather
+  than the documentation's, reaches the right concepts first when it is asked
+  as two to four sub-questions in the words of the bundle's own map (`okf card`
+  / `okf_describe`), which is the working method the skill and the server
+  state. Asked raw, it may be answered from the wrong concepts, and
+  `coverage.weak` is a reading, not a guarantee, that this happened.
+- **The answer quality of v1.1 was checked on five questions, not measured.**
+  Five answers, each written by a fresh model context from one call over a
+  folder of two bundles, graded by hand. What showed red: one answer carried
+  the right content without the wording the grading required, and the helpers
+  did not always keep to one call. The question the bundles do not cover was
+  declined rather than answered. Five questions is a smoke test, not a rate;
+  the questions, answers and counts are about a consumer's corpus and are not
+  published here.
+- **Speed was not measured for v1.1**, and neither was what a folder reply
+  costs a client's context limit on a large folder of bundles.
 - **The content accounting counts the element classes its vocabulary names, and
   no others.** `0 unaccounted` is a statement about those classes, not about the
   document: a file whose suffix has no reader is accounted at file level only,
@@ -188,11 +209,11 @@ Neither this package nor the guard it depends on is on a package index yet, so
 both install by direct reference. With uv, one command resolves both:
 
 ```sh
-uv pip install "llm-ingestion-okf[extract] @ git+https://git.fromaitochitta.com/open/llm-ingestion-okf.git@v1.0.0"
+uv pip install "llm-ingestion-okf[extract] @ git+https://git.fromaitochitta.com/open/llm-ingestion-okf.git@v1.1.0"
 ```
 
 uv resolves the guard on its own, because it reads the `[tool.uv.sources]`
-entry in the `pyproject.toml` **of the tag it is installing**, and `v1.0.0`
+entry in the `pyproject.toml` **of the tag it is installing**, and `v1.1.0`
 points that entry at `llm-ingestion-guard` `v1.4.0`. Use `uv tool install`
 instead of `uv pip install` when you want the `okf` command on `PATH` without an
 active virtualenv — that is the form the first screen shows.
@@ -203,10 +224,10 @@ With plain pip, the transitive git dependency does not resolve on its own —
 
 ```sh
 pip install "llm-ingestion-guard @ git+https://git.fromaitochitta.com/open/llm-ingestion-pipeline-security.git@v1.4.0"
-pip install "llm-ingestion-okf[extract] @ git+https://git.fromaitochitta.com/open/llm-ingestion-okf.git@v1.0.0"
+pip install "llm-ingestion-okf[extract] @ git+https://git.fromaitochitta.com/open/llm-ingestion-okf.git@v1.1.0"
 ```
 
-The guard tag is paired to the okf tag, not to this branch. `v1.0.0` declares
+The guard tag is paired to the okf tag, not to this branch. `v1.1.0` declares
 `llm-ingestion-guard>=1.2,<2.0`, which `v1.4.0` satisfies; the pairing above is
 read off that tag's own `[tool.uv.sources]`, not off this branch. Reading a pin
 off `main` and installing it against an older okf tag is the one combination
@@ -217,8 +238,12 @@ that fails.
 These are not install lines. They record what each earlier tag was, so a reader
 who meets one in an older document knows what they are looking at.
 
-- `v1.0.0` — the current tag, and the version this tool is finished at. It
-  adds no capability to `v0.10.1`: a document the gate refuses whole is now
+- `v1.1.0` — the current tag. The reading side: BM25 ranking on passages and
+  titles, several sub-questions in one call, a map per bundle, a signal for
+  weak coverage, and one generic skill plus the server as the standard way in
+  over a whole folder of bundles. The payload contract is `okf-consumption/2`,
+  which breaks a reader of `withheld` as a list. See the CHANGELOG.
+- `v1.0.0` — the tag v1 was finished at. It adds no capability to `v0.10.1`: a document the gate refuses whole is now
   named in the run's own summary with its code and with the one command that
   carries it anyway, and the front page states what this tool does not do.
   Read [Known limitations](#known-limitations) before you depend on it. After
@@ -1231,7 +1256,7 @@ not need this repository — the first line installs the command, the second
 builds the bundle and writes a skill beside it, the third asks.
 
 ```sh
-uv tool install "llm-ingestion-okf[extract] @ git+https://git.fromaitochitta.com/open/llm-ingestion-okf.git@v1.0.0"
+uv tool install "llm-ingestion-okf[extract] @ git+https://git.fromaitochitta.com/open/llm-ingestion-okf.git@v1.1.0"
 okf project ~/my-documents
 claude
 ```