conandeps: always show the binary's source; cache-only binaries are not available

The tool's question is "does the remote have this binary?", so local cache
state must not mask the answer. Conan reports Cache for a locally present
binary without consulting the remote; for those nodes we now run a package
search on the remote(s) and only count the binary as available if the same
package_id is found there. Binaries that exist only in the local cache are
rendered as "not available", listed under missing binaries with a note, and
make the exit status 1.

Every available cell now names the remote that has the binary instead of a
bare "ok". Adds a test that builds a package locally without uploading it
and checks it is reported as cache-only.

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

CLAUDE.md

@@ -37,6 +37,12 @@ for what it does and how it is used.
   replace this with settings-dict matching against `conan search` output.
 - **"Missing" means missing for the exact profile.** Not "no binary with
   that build_type at all".
+- **Only the remote counts, and the source is always shown.** Conan says
+  `Cache` for a locally cached binary without asking the remote, so
+  `_RemoteIndex` verifies cache hits with `search_packages` on the remote.
+  Cache-only binaries are reported as `not available` and count as a
+  problem (exit 1). Every available cell names the remote. The user rejected
+  an opt-in flag for this – it is the tool's core question.
 - **Overrides are parsed from Conan's WARN output.** Conan 1 does not record
   overrides on the graph; `Requirements.update()` mutates `req.ref` in place
   and only emits `"<pkg>: requirement <old> overridden by <who> to <new>"`.