docs(vendor): the nested vendor.status can turn success after an early lock refusal

The depscan vendored gate showed the one envelope difference the V-4a docs
did not name: with its 3 lock-text refusals moved to the download phase,
the vendor step has no failures left, so vendor.status goes
partialFailure -> success (the top-level status and the exit code stay
partial_failure/1). Say so, and name the human arm's message when every
selected package is refused this way.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Author: mikolalysenko

CHANGELOG.md

@@ -50,7 +50,11 @@ into the new version's section — see docs/releasing.md.
   `download.failed` rises by the number of such packages, and the vendor
   envelope no longer carries their `failed` events (`vendor.summary.failed`
   drops by the same number) nor, for lockfile-only packages, their
-  `vendor_fetched_missing` events. Exit code and `status` are unchanged.
+  `vendor_fetched_missing` events. Exit code and the top-level `status`
+  are unchanged; the nested `vendor.status` becomes `success` when those
+  refusals were the vendor step's only failures (and when every selected
+  package is refused this way, the human arm prints `Nothing was
+  vendored: N patches failed (see above).`).
   (The interactive human `scan --vendor` arm still fetches the views its
   pre-prompt baseline check verifies.) Purls the hosted redirect ledger
   claims keep the vendor loop's refusal. Because no view is fetched, the