fix(inbox): refuse a segmentation plan that matches no dropped file

A plan is selected by content hash, so a mistyped source_sha256 matched
nothing, every dropped file fell through to the one-concept rule, and
process_inbox returned an ordinary success over a flat bundle. The
operator asked for segmentation, got none, and had no error to read --
the silent skip this library refuses everywhere else. vegnormal-okf is
about to run an N500 corpus through this path, where a silent zero
would read as "the corpus has no concepts".

The refusal asks whether a covering plan was FOUND, not whether every
file was examined, so an unreadable drop cannot mask it; and coverage
is recorded at selection, not after path validation, so a matched plan
with a refused entry path still reports its own per-file code. The
first cut got that second question wrong and an existing collision test
caught it; the case is now pinned by its own test, verified red against
the earlier form.

New code segmentation_plan_unmatched, registered in the SegmentationError
docstring register in the same commit. Fail-fast before any disk
mutation. The four existing goldens are byte-identical to baseline.

Co-Authored-By: Claude <claude-opus-5>

src/llm_ingestion_okf/errors.py

@@ -177,6 +177,12 @@ class SegmentationError(IngestError):
       offset had silently moved
     - `segmentation_unsupported_profile` — a plan was passed to a profile that
       does not declare the segmentation capability
+    - `segmentation_plan_unmatched` — the plan is well-formed but its
+      `source_sha256` matches no dropped file, so nothing would be segmented
+      and the run would report an ordinary success over a flat bundle. A
+      mistyped hash is the likely cause and it is unreadable from the result;
+      refusing is the only way the operator learns that the judgement they
+      adjudicated was never replayed
     """